[Nut-upsdev] upsdrv_print_ups_list and afferant reflections

[Jonathan Dion]

> 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
===
.
.
.

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
 - 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.

> You could also, for the purpose of this list, list each newhidups
> subdriver separately.
>

With the first aproach, it would not be needed anymore

> -- Peter
>

Your opinion ?

For the driver structure (with name, version and so on), there is no
need for a status field, as you stated it out. But it still have the
advantages the regroup those information near of the header of the
source file (easier to maintains) and reduce the number of functions
that need to be in each specific driver source code (upsdrv_banner,
upsdrv_help for instance)
As it regroup thoses functions, it insure a standrat format for them
(and if we want to change the way the banner is printed, we only have
one function to modify).
Only functions that are really specific to driver should be in driver
specific source, all the rest should be in main.c

It is more of a cleaning operation, not a critical change. So do you
think it is worth the change ?

Jonathan