Citeren Arnaud Quette <[EMAIL PROTECTED]>: > the use of defines for VendorID is due to the fact that that way, we > can extract the comment on the line before the #define (Vendor Name, > ex Agiler), and keep the one above the device declaration > (USB_DEVICE...) for the device (ex Agiler UPS).
Thats a flawed strategy from the start. :-) We already know that some VendorIDs will have a much larger set of devices, especially in the world of USB to serial converters where this driver lives. For instance, what we now call BELKIN_VENDORID, is in fact the vendor ID of Cypress Semiconductor, for which we know in the mean time that there loads of OEMs that use it. Although this looked like a good idea, it doesn't work. > though that's purely informative and cosmetic, it may be useful... The reason why I removed this here, is the fact that over-use of defines makes code more difficult, instead easier to understand. What we're matching here, is a combination of VID:PID. When users report 'new' models, these will invariably be in hexadecimal (as reported by 'lsusb') format. This table should reflect this, so that it is immediately clear when looking at it if a combination is new or not. Using defines obfuscates this. So while I agree that automatic extraction of information from the code is useful, in this case I think you went one step too far. Extracting this on a VID:PID level is as far as I would like to take this (and even then we should remember that there will be an awful lot of duplicates). Best regards, Arjen -- Please keep list traffic on the list _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
