[Nut-upsdev] ambiguous USB IDs

[Arnaud Quette]

Hi guys,

a quick message from the FossCamp since I've not yet had time to
answer to Arjen about the removal of the megatec_usb hal-addon ...

2008/12/4 Arjen de Korte <nut+devel at de-korte.org>:
> Citeren Charles Lepple <clepple at gmail.com>:
>
>>> Another thing, loosely related to this, is how we are going to deal with the
>>> 'generic' VID:PID combinations in some of the USB drivers, for example the
>>> megatec_usb and (new) blazer_usb drivers. At present, in the megatec_usb
>>> driver we have several VID:PID combinations for USB-to-serial converters
>>> that are commonly found in UPSes. But what happens if other totally
>>> unrelated (non-UPS) devices use the same controllers? Or that kernel level
>>> support becomes available for them?
>> Maybe we split the udev files for ambiguous IDs into another package
>> (enabled at configure time, disabled by default)?
>
> This would
>
>>> Unless a VID:PID combination unambiguously identifies a USB device as a
>>> supported UPS, using it in a HAL addon is probably not a very good idea.
>>> Should we remove the 'hald-addon-megatec_usb' driver before releasing
>>> nut-2.4?
>> I haven't looked much into the new structures, but could we add
>> another field to specify whether it is an official VID:PID, or if it
>> looks suspect? That could help with splitting the udev files as
>> mentioned above.
>
> We could do this more easily by adding another macro, like the
> existing one that is used to extract the VID:PID combinations:
>
>        /* dummy USB function and macro, inspired from the Linux kernel
>         * this allows USB information extraction */
>        #define USB_DEVICE(vendorID, productID) vendorID, productID
>        #define USB_LIKELY(a, b)        USB_DEVICE(a, b)

this is the approach I have in mind... at first, I thought about
another field in the struct, but it's not worth, at least for the
moment.

I'll be presenting the Power * subject in 15 mn...

cheers
Arnaud