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

[Martin Owens]

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

Ah sorry for the past links, try the latest I've removed the
dependancies on an /etc/ conf that was stopping it from running.
(requires python/gtk/hal)

http://divajutta.com/doctormo/do.tar.bz2

Back on topic:

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

OK

> 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 ;-)

I wasn't going to limit the list by using any probing. I was just
going to make list easy to select from.

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

The available drivers arn't an issue to me, if the computer computer
supports a device, great. if not never mind. but it still needs to be
defined and known. which is why I wanted to keep definition seperate
from device binding.

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