Re: Serial design

[Russell K. - A. L. <li...@ar...>]

(Could you please ensure that your mails are wrapped at less than the
80th column please to save me the bother of doing this for you?)

On Tue, Dec 18, 2001 at 11:57:43AM -0800, James Simmons wrote:
>    III. The final step is when a device is detected that we map it to a
>	  specific port. For example if the bus detects a modem then it
>	  would only make sense to map the struct uart_driver that
>         represents the tty interface to the port that the modem wants
>         to use.

Are you proposing here that any ports should not be attached to any drivers
until something is detected on the other end?

If so, are you sure this is a good idea?  To give an instance, if I were
to connect two machines together using the serial ports, both of which are
running this serial driver, how would they know that they had been connected,
and more imporantly that they shouldn't use a keyboard driver?

> 2) The structures to represent the hardware and device interfaces. Now
>    with the data we want to have data structs that define the hardware
>    state and be able to change that state.

How is this different from what we already provide in the uart-based drivers?
It appears that you've described the current setup in I and II rather well.

>    III. struct uart_driver. The data here presents the device interface
>         used to represent the hardware. This struct should be interface
>	  independent. 
>
>	  A void field would be added to this struct which could be cast
>	  in the higher device level. That data field would depend on the
>	  device interface.  

Hmm, untyped data pointers.  Ewww.