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