[Nut-upsdev] upsdrv_print_ups_list and afferant reflections

[Peter Selinger]

Jonathan Dion wrote:
> 
> > I think being "stable", "supported" etc is not a property of drivers,
> > but a property of pairs (x,y) where x is a driver and y is a device.
> > Generally, even drivers that have been stable for years might not
> > work perfectly with a new device. This applies to all drivers, not
> > just newhidups.
> >
> Yes, you are rights. It is more a property of pairs (device, driver)
> than of the driver itself.
> The current driver.list don't have enough information to do it.
> 
> I think of completing the print-ups-list function to be able to give
> all this information. That is to say that for instance, an execution
> of "mydriver -l" would return :
> 
> MyDriver version x.y.z...
> 
> List of Supported UPSs
> ===
> Name : UPS1
> Vendor : TheVendor
> Extra : USB
> VendorID : 0xXXXX
> ProductID : 0xXXXX
> Status : Supported
> ===
> Name UPS2
> Vendor : TheVendor
> Status : Unstable
> ===
> .
> .
> .

Make sure you make the format flexible enough that: (1) all whitespace
before/after ":" and at the beginning/end of the line is ignored
(there should be no difference between "Name: X" and " Name : X "),
(2) case is ignored in keywords (vendorID, Vendorid etc), (3) blank
lines are ignored, (4) include some format for comments, and (5) if
lines of the form "===" have a special meaning, make the rule for this
flexible (e.g., any line starting with "=" after whitespace).

In short, even though this format is machine-generated, it should still
be human-editable, just in case.

> That is to say not only the vendorID and ProductID as it is the case
> now (when it as a sense, only USB UPS), but also all the information
> that is actually contained in driver.list
> 
> With those information in the drivers, I can make all the output
> needed, and even generate the driver.list from it
> 
> The advantages I see :
> 
>  - Only one source of information, and it is the more logical I think
> (it is logical that driver know what they support)
>  - Expendable. The problem of driver.list is that it is not expandable
> without modifying all the program that use it.
>  - All needed output can be generated from it. (fdi, udev, hotplug,
> html array, driver.list and so on)
>  - For further graphical configuration application, you can list the
> UPSs that are supported by an installed driver. If you install a new
> driver, the list of UPS it support would be automatically added to the
> list of UPSs supported by your system
> 
> Disavantages :
> 
>  - An user only have the list of UPSs that are supported by a driver
> he or she have installed, and not a full list. But us developper who
> have all the drivers, we can generate the full list, so the user can
> know which driver to install

Yes, there should be a target such as "make maintainer", which builds
all the lists and other things that the maintainer needs to
build. (This would include, for example, the target "make depend" that
already exists in the drivers/ directory, and the new driver lists in
all relevant formats).  It should be a prerequisite to a "make dist"
target that builds an actual distribution.

>  - If a new product appears, it would need to modify the driver so it
> appears as supported (even if in the fact it would support it). But
> for us developpers, add a new product just imply add it to the
> corresponding driver(s), and then run a tool to update what need to be
> updated.

This is no different than what we already have. When a new product
appears, it currently needs to be added to driver.list manually, even
if the driver already works for it.

The drivers, of course, should try to work even with products that are
not explicitly listed. 

-- Peter