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

[David Zeuthen]

On Thu, 2006-09-07 at 17:49 +0100, Martin Owens wrote:
> I'm not so sure this is the right way around. because serial ports are
> not automatic we should use the user to our advantage:

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.

> Instead of probing the port for hardware you have in hal the fact that
> there is a serial port (I'm sure this is in the bios some place, abut
> what IRQ ect for what serial port) on the computer should be made
> available in HAL. 

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.

> Then my program can see there is a serial port and allow the user to
> select the device connected to the port. 

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?
 
> having the ability to create new device definitions will be important
> and allowing the probing to then take place on a device by device
> selection basis. 

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. 

And in the event that the driver sports a "generic" driver we simply
just require that it exports the configuration of said driver as
multiple device id's cf. my mail.

> Once selected my program modified HAL (create a new node) and saves an
> fdi file for that serial port saying what the child node is model,
> manufacturer, name, capabilities anything you want (not sure if this
> is possible in HAL but it should be) 

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.

> another program listening to hal can pick up on the changes and probe
> the serial port further if it wishes. modem software ect can see the
> device by it's capabilities and use it.
> 
> What do you all think?

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.

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

     David