I want to propose to change the format of the entries in the data/driver.list file. Currently the format is (according to the header) # <manufacturer> <model name> <model extra> <driver> Of these fields, the <model extra> field is not very well defined now. For many devices, it contains information about the communication interface used (serial / USB / SNMP) while for others it says something very model specific (for instance, which cable to use) or which protocol the UPS uses. Now that we're seeing more and more UPSes with both serial and USB connections, I think it makes sense to add another (mandatory) field that lists the communication interface used by the driver. This allows for easier sorting of the list of drivers, now that the list is growing. I also want to suggest that if a UPS has both serial and USB interfaces, but we currently only support one, that we mention the other too with 'not supported' in the <driver> field. This will help users determine quickly (and unambiguously) if they can use the interface of their choice with NUT. Any thoughts? Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57
Arjen de Korte wrote:> > I want to propose to change the format of the entries in the > data/driver.list file. Currently the format is (according to the header) > > # <manufacturer> <model name> <model extra> <driver> > > Of these fields, the <model extra> field is not very well defined now. For > many devices, it contains information about the communication interface > used (serial / USB / SNMP) while for others it says something very model > specific (for instance, which cable to use) or which protocol the UPS > uses. Now that we're seeing more and more UPSes with both serial and USB > connections, I think it makes sense to add another (mandatory) field that > lists the communication interface used by the driver. This allows for > easier sorting of the list of drivers, now that the list is growing. > > I also want to suggest that if a UPS has both serial and USB interfaces, > but we currently only support one, that we mention the other too with 'not > supported' in the <driver> field. This will help users determine quickly > (and unambiguously) if they can use the interface of their choice with > NUT.No objections to this, except I think we should say "not supported" only in cases where it has been confirmed that the model does not work with any NUT driver (like the Kebo). Most often, we simply don't have the information on whether it works or not. For example, no user has yet tried the Belkin F6C1200-UNV with the serial port, but it's likely that it would work with the megatec driver; similarly with the F6C100-UNV and the belkinunv driver. In such cases, we should continue to list it neither as "supported" not "unsupported". -- Peter
On 5/22/07, Arjen de Korte <nut+devel at de-korte.org> wrote:> I want to propose to change the format of the entries in the > data/driver.list file. Currently the format is (according to the header) > > # <manufacturer> <model name> <model extra> <driver>[...]> Now that we're seeing more and more UPSes with both serial and USB > connections, I think it makes sense to add another (mandatory) field that > lists the communication interface used by the driver. This allows for > easier sorting of the list of drivers, now that the list is growing.I can't find the exact script that parses this list (and I'm running out of time on my lunch hour) but I think the format has been implicit up to now. Do we want to take this time to consider another format that is easier to extend in the future? I'm thinking of a key-value arrangement, much like the config sections in ups.conf. Additional keywords might include the "model year" to distinguish between UPSes with the same model name but different innards.> I also want to suggest that if a UPS has both serial and USB interfaces, > but we currently only support one, that we mention the other too with 'not > supported' in the <driver> field. This will help users determine quickly > (and unambiguously) if they can use the interface of their choice with > NUT.How about "needs testing" in addition to "supported" and "unsupported"? A while back, Ross Vamos-Wentworth (sp?) had a larger database of peoples' experiences with various UPS models and drivers. Maybe we could have a similar system where people can report success or failure online. (This would be more up-to-date than the autogenerated HTML driver list.) -- - Charles Lepple
2007/5/22, Arjen de Korte <nut+devel at de-korte.org>:> I want to propose to change the format of the entries in the > data/driver.list file. Currently the format is (according to the header) > > # <manufacturer> <model name> <model extra> <driver> > > Of these fields, the <model extra> field is not very well defined now. For > many devices, it contains information about the communication interface > used (serial / USB / SNMP) while for others it says something very model > specific (for instance, which cable to use) or which protocol the UPS > uses. Now that we're seeing more and more UPSes with both serial and USB > connections, I think it makes sense to add another (mandatory) field that > lists the communication interface used by the driver. This allows for > easier sorting of the list of drivers, now that the list is growing. > > I also want to suggest that if a UPS has both serial and USB interfaces, > but we currently only support one, that we mention the other too with 'not > supported' in the <driver> field. This will help users determine quickly > (and unambiguously) if they can use the interface of their choice with > NUT. > > Any thoughts?a side note first: I've started reviving the HWDB (HardWare DataBase) idea not long ago with an Ubuntu friend. The main idea is to have a central HWDB (either one per distro, or a real central one), pulling the compatibility data from the upstream projects (ie NUT drivers.list for NUT, my underway work lirc.hwdb for LIRC, LinuxPrinting.org data, ...). And the best would be to have a generic format that fits every projects needs, and allows to make generic submission forms that would be relayed to the upstream projects. I'm thinking about submitting some standardization spec to FreeDesktop or alike, but still miss time to complete this. If somebody is interested in, I'd be more than happy to assist him and free a bit more my brain ;-) About your proposition, I would so see something more complete, including: - support level (not tested, not working, working (possibly adding reverse engineered or alike tags) - specific port info (USB IDs, ethernet port/protocol, ...) - Charles proposition of key-value pairs seems a good generic way - we should be able to generate the various file from this (html, hotplug, udev, hal) Other notes: - the script generating the current html lists isn't in the repository. Russell sent it to me apart, not so long ago. It's binary using parseconf. If someone is interested in, I've put it there: http://opensource.mgeups.com/beta/tools/ - The work done by Jonathan last year lies in the HAL branch. The compat data are embedded in the drivers (I don't much like this, but the base idea was to eliminate compat. info redundancy, and I've not find better). The tool used to generate the various lists (hotplug, udev, hal, html) is in utils/print-ups-list.c - Ross' list was too heavy to manage, though his effort was great to do so! I might have missed many details, but it's part of my "long run ideas that never got completed enough" Arnaud -- Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ OpenSource Developer - http://arnaud.quette.free.fr/