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 <[EMAIL PROTECTED]>: > Citeren Charles Lepple <[EMAIL PROTECTED]>: > >>> 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 _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
