[Nut-upsdev] Re: Serial Ports (Was Re: Common Power Management : NUT and HAL (stage 1))

[Martin Owens]

Under text will appear when required... messages follow.

On 9/7/06, David Zeuthen <david at fubar.dk> wrote:
>
> Never claimed they were, that's why the user get to pass two options
>
>  - the type of device (e.g. UPS, modem);
>
> and when he has selected that he gets to select
>
>  - the make and model of the specific device type, e.g.
>    - "AEC MiniGuard UPS 700 Megatec M2501", "Ablerex MS-RT" for UPS
>    - "Generic Serial Modem", "US Robotics XYZ42" for modems
>    - "Wayfinder ABC42", .. for GPS etc.
>
> and that's fine.
>

Yes ok I think then we are converging on the same ideas but from
different perspectives.

>
> It already is available and we don't automatically probe it. This
> proposal is about binding a specific driver (user space mostly) to a
> port we cannot probe.
>

I don't want it to bind the driver to the port (unless is normally how
HAL works) all I'm concerned with is allowing the user to select the
correct type/make/model and for that information to be stored in HAL
against the port. what a driver does after that, or what driver
attaches it's self I'm not really interested in since I can't program
the UI to deal with specific drivers or specific cases it would be a
generic interface allowing you to attach information to HAL.

>
> It is the explicit goal of this proposal to allow such UI to be
> written ... and for preserving the sanity of the user we just restrict
> how much we want to bother him. It should be enough just asking for the
> type + make/model. Do you have anything that suggests otherwise?

No, that's a fair way to select hardware.

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

>
> This is exactly what this proposal is about: making it easy to build UI
> for the user to bind a driver to a device on a port that cannot be
> probed.
>

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.

> I'm not sure exactly what you're saying or what you think is wrong with
> the proposal. It would be good if you can come up with specific examples
> too.

Sorry for being obscure, I'm trying to be as clear as possible about
the effects.

> Btw, please start using the standard conventions when participating on
> mailing lists (no HTML, reply under quoted text etc. etc.). Thanks.

sorry about the html, I didn't realise gmail was outputting html.

>      David
>

Best Regards, Martin Owens