Serial Ports (Was Re: Common Power Management : NUT and HAL (stage 1))

[Arnaud Quette]

Hi fellows,

first to Martin: you never replied about my problem running "do"...
can't run it, can't try it!

second, always remember we're trying to add support for dumb legacy
devices, not able to enumerate their capabilities, and not allowing us
to perform auto binding, as with USB et all...

as you both told, a GUI and user action *are needed*.
But following the user choice, we must have all the needed info to
start the driver. Thus the intelligence must come from the layer
presenting the dev. list, the driver bound to each dev, and possibly
the driver options (ie not the one mandatory such as for the
genericups type in my previous example).
Maybe the "serial prober" notion is there. a generic thing that
propose the list of "mfr<sep>model<sep>driver_and_mandatory_options"
as we offer with the nut drivers.list, but served and formatted by a
"prober" in an HAL suitable format.

more below...

2006/9/7, David Zeuthen <david at fubar.dk>:
> On Thu, 2006-09-07 at 18:32 +0100, Martin Owens wrote:
> > > I don't really know what you mean by "device definition", can you
> > > elaborate? Keep in mind that adding support for new devices need to
> > > happen at the driver level anyway.
> >
> > Support for device needs to happen at the driver level, but
> > information about the device can exist without the need for a driver
> > to exist, even if the purpose of the information is to say that the
> > hardware doesn't yet work but such an such a group of people are
> > looking into getting it to work. support for the device is nice but
> > not essential.
>
> So what you want is the ability to pass more than just
>
>  type="modem", make/model="Generic Modem"
>
> you want to e.g. pass
>
>  type="modem", make/model="Generic Modem", knob1="foo", knob2="bar", ...
>
> from the UI. Is this correct?
>
> Let me tell you that's a really bad idea since it will
>
>  - clutter the UI and confuse the users
>  - make things a lot more complicated
>  - make it harder for the user to get this right
>
> so unless it's really needed I don't want that.
>
> And how can it really be needed? I suppose one example would be a
> super-generic driver with 42 knobs and the permutations of all these
> would yield a device list that is very long. In a way, you could simply
> call that driver broken for providing all these options. But maybe some
> drivers are like that or needs to be like that because hardware sucks.
> Again, specific examples needed.
>
> > I think your thinking about a specific kind of UI which would before
> > modems, or perhaps one for ups which would contain a database of
> > supported hardware and bind the port to the correct driver. my idea is
> > to allow you to use information available in HAL to use the correct
> > driver without having your down database which would need to be
> > updated. if you knew a new kind of ups worked with an existing driver,
> > I could connect the two by providing the right information to HAL
> > without you updating your UI or drivers.
>
> Why wouldn't you just want to patch the driver / HAL glue to provide
> this extra information? Then the user would simply just select their
> make and model. Of course, it takes some time for this to bubble down to
> the distros but such is life.
>
> I'm reluctant to add these extra options because of the huge cost they
> have (see above) - what you're suggesting is to have _key information_
> about what hardware a driver supports live in another place than the
> driver. And that, in many ways, is wrong because if you don't have the
> right infrastructure for delivering this information it'll just end up
> on various forums and the poor user is back to googling to get his
> hardware to work.
>
> That's not "Just Works(tm)", it's rather the opposite.

note that we have a chicken and egg dilemna here: you need to propose
the user a list of supported devices in which to pick his one (to bind
the right driver), and this list is available ... from the drivers!
hugh ;-)

we've anticipated it in nut (svn branches/HAL) by:
- adding a "-l" option to the drivers, which allows to embed the
supported devices list into the drivers. The output format is parsable
and is:

- using the above in the print-ups-list helper which iterate on all
the drivers to generate the complete drivers.list, in parsable text
form. As stated a the beginning of the mail, we can derive a "prober"
from this, presenting this list in the HAL way, and upon driver
selection, calling this one to get the driver's option using the below
"-L"... Then expose it, still in the HAL way, and ie g-p-m can propose
a list of "Advanced params" opaque but easily manageable (the type and
desc should be sufficient!).
Get the big picture?

as a side note, nut drivers also have a "-L" to print parseable list
of driver variables in the form:
# format: vartype<sep>varname<sep>vardesc
VALUE upstype "Set UPS type (required)"
FLAG someflag "Activate someflag"

I can elaborate more on this, but with a bit of lag...

> Also keep in mind that the actual capabilities and methods exported,
> when we have configured a legacy port will allow further configuration.
> For example, I suppose the bespoke "modem" addon would export a method
> in the API to configure certain things like the modem initstring etc.
>
> Again, this is pointless to discuss without specific examples. Do you
> have any? And it's not like we can't add this later on, it'll take a
> while for this part of the API to be baked anyway. It's not even written
> yet!

Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/