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

[David Zeuthen]

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.

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!

    David