[Nut-upsdev] upsdrv_print_ups_list and afferant reflections

[Jonathan Dion]

On 8/9/06, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> 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.

No problem for all that. It is done.
# is the comments escape character

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

Arnaud was exactly thinking the same thing

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

Yes, you are right. And it needs to manually modify udev rules and
hotplug usermap too. The goal is not to have to do all this anymore,
but just to add the driver once.

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

Yes, I understanded it from the precedent mails in this thread. I
won't modify the claims functions.

>
> -- Peter
>

Ok, I'll begin to do that then.

Cheers,

Jonathan

seen in linuxfr.org : schizophrenia is the fork of geek