[Nut-upsdev] upsdrv_print_ups_list and afferant reflections

[Jonathan Dion]

Hi NUT,


On 8/3/06, Charles Lepple <clepple at gmail.com> wrote:
> On 8/3/06, Jonathan Dion <dion.jonathan at gmail.com> wrote:
> > Would something like  :
> >
> > List of supported UPSs
> > ===
> > VendorID: 0x1234
> > ProductID: 0x5678
> > ===
> > VendorID: 0x9012
> > ProductID: 0x3456
> > ProductInfo : All UPS of XX vendor
> > ===
> > .
> > .
> > .
>
> That's what I meant for the key-value idea. It looks suspiciously like
> the output of upsc :-)
>
> > I though again about using my new parser and format for that. It would
> > become something like :
> >
> > #List of supported UPSs
> > supported_ups (
> >       mge-hid1 (
> >             VendorID = "0x1234"
> >             ProductID = "0x5678"
> >       )
> >       mge-hid2 (
> >             VendorID = "0x9012"
> >             ProductID = "0x3456"
> >             ProductInfo = "All UPS of XX vendor"
> >       )
> >       belkin-hid1 (
> >             VendorID = "0x1234"
> >             ProductID = "0x5678"
> >       )
> >       ...
> > )
> >
> > The advantage is that the parser exist (I just have to create a
> > entrance point that parse stdin and not a file, it is easy and quick),
> > and that it make a tree structure that is easy to manipulate. (and you
> > can add any information you want, it is absolutly expandable) We also
> > have information about which subdriver supporte which product.
> >
> > What do you think of it ?
>
> As far as I am concerned, either one is OK. I think it really depends
> on where the information is going to be used.
>
> (If I were to write the code, I would probably just write a perl
> script or something to parse it, but there are definite advantages to
> reusing the same parser to reduce the number of different syntaxes we
> have floating around.)
>
> --
> - Charles Lepple
>

I finally choose the first approach, as the configuration formalism is
not really adapted for that. (It can do it, but the first output is
more "common" and then more readable).

The list can be obtain with the option -l (it is a lower case L, not a
upper case i) of the drivers (new option).
I made a table of supported device in drivers. As we discuted before,
I didn't modify the claims function to use this structure. There still
are reflection to do before doing it.

I also made a tool that create fdi file for HAL, rules for udev and
usermap for hotplug, nammed print-ups-list (Inspired from the
print-camera-list of gphoto 2). I commited it in the HAL branch
(svn://svn.debian.org/nut/branches/HAL)

I you want to try you need to make ./configure to make the Makefile,
then go in utils directory, do make to create the tool. The tool use
newhidups, so be sure it is compiled too.
use print-ups-list -f for fdi output
print-ups-list -u for udev output
print-ups-list -p for hotplug output (didn't find a better option
name, if you find a good one for hotplug usermap (u and h are already
used)


As Peter pointed it out, the array of supported UPS is another story.
I think it is a good idea that the same tool can make it, but it will
mainly use driver.list to do it.

Arnaud want to have color for the status of the driver (stable,
unstable, supported by producer, from reverse engineering, ...). For
that, I need to make the structure I spoke of before (with driver
name, version, author, maintener, status and so on).

The problem is for newhidups driver. It is one driver, but some
subdriver are supported by producer, and some other are made from
reverse engineering.
And as it is an automic driver (through claim function), wich
subdriver is used don't appears in the driver.list.
Do you see a way to make something about that ? What is your opinion ?

What ever is the solution (if there is one), I think the structure is
a good idea. (no need to have anymore upsdrv_banner and upddrv_help
function in each driver, it regroup important information, ...)
I though of the following data. Do you see others that could be of
interest ? Is there a variable name that could be better chosen ?

drv_name : name of the driver
drv_vers : version of the driver
drv_maintainers : who to contact if pb with the driver
drv_authors : people who contributed to the driver
drv_status : stable, unstable, testing
drv_sources :  suported by the vendor, from reverse engineering, and so on
drv_help : an help text. (corresponding to the upsdrv_help function)

Cheer,

Jonathan Dion