[Nut-upsdev] upsdrv_print_ups_list and afferant reflections

[Jonathan Dion]

Hello ups-dev

Arnaud asked me to add a function upsdrv_print_ups_list the drivers

upsdrv_print_ups_list : why

This function would print the vendorId and the productId of the UPS
supported by the driver (for USB driver at least). It could then be
parsed by a tool (that I'll have to make too), whose the goal would be
to automagically generate 4 sort of file :
 - fdi file for HAL
 - udev rules file for udev
 - hotplug usermap for hotplug
 - Html array to have a compatibility list

This way, one just have to modify a table in the driver to says which
UPS it support and then to run this tool, and no more have to manually
create those 4 files.

In the same time, we could create a structure that contains the
VendorId and ProductId supported, and introduce then a generic way to
make a claim function.

For the moment, some claim function just look at the VendorId. But a
vendor can do other things than UPS, or make a new UPS that don't use
the same USB protocol as the last UPS this vendor created, leading to
a subdriver that claim an hardware it cannot support. Having a list of
supported UPS and looking for match as well in VendorId and in
ProductId solve this problem.

But it bring another problem (life is never simple ;-) : What if a
producer make a new product under a new ProductId, but this product
can perfectly be managed by the subdriver ? Would the users have to
manually modify the sources of the subdriver to add this productId and
compile NUT again ? Or would they need to wait the next release for us
just to add a line in a driver ?

A way to solve it would be to externalize this information out of the
driver, to allow users to modify it. But, as pointed out Arnaud, it
first can be dangerous if a user make a mistake, and secondly, if a
user find a couple of VendorId ProductId that is in fact supported by
a subdriver but not in the list yet, there are chances that this user
would not tell us about it (and then we won't add it in the next
release).

As a compromise, I propose to let the information in the drivers, but
to add a way to force newhidups to use a specific subdriver without
using the claim function.
This way, as user cannot modify it easily, we have more chance he or
she will ask the question on the list. if we would find that this UPS
is supported but not added in the list yet, we will add it in future
release (for the benefit of all users), and until the next release is
out, we can answer the user that he or she can force the use of this
subdriver without any risk.

Do you have any comment about it ? reactions ?

Your faithfully,

Jonathan Dion