Re: Serial design

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

On Sat, Dec 22, 2001 at 09:37:09PM -0800, James Simmons wrote:
>    Hm. That depends on the hardware and/or hardware setup. For example on
> the iPAQ one serial port is used just for the touchscreen.

It's actually used for a microcontroller which handles the touchscreen and
many other things (like power management).

> The other for IR

Forget that port - the sa1100_ir driver is far superiour for driving it.

> and the first serial can be used for serial console/tty stuff or a
> stowaway keyboard. With the stowaway keyboard it sends a signal. So here
> we have smarter hardware. So fixed port are easy. 
>    The second class is using the bus like the PCI/PNP layer to find out
> what got attached. 

This sounds a somewhat Microsofty solution.  Do we really want the kernel
sending stuff like 'AT' commands at various baud rates to the connected
machine, which might be waiting for you to "press any key" after changing
the floppy?

>    Then we have the total dumb serial port. In this case if we can't
> figure if anything is attached or if something attaches and we don't know
> what it is then prehaps we should default to using the tty layer. Or
> better yet let the user load the right modules. 

Your only connection to the machine is over this serial port.  How do you
load the modules if you're not connected to the machine?

> Their is no difference. I based these ideas on what you have done. Your low 
> level setup is perfect from what I can see. Well except for touching 
> struct uart_info. I still need to figure a cheap way to send data from the
> low level to the user uart_driver level. Most likely I will add a rx_char
> and tx_char function to struct uart_driver.

I'd rather see a generic buffering layer between the serial low level and
upper levels (and do away with the tty flip buffers).  I think that will
separate it sufficiently.

Also, I don't see an easy way to get rid of uart_info from the low level
drivers - its used for many things, including maintaining correct locking
on SMP.

> Also maybe a shutdown or connect function?

Erm, don't we have 'startup' and 'shutdown' functions already?

> Well the higher data structures are a bit messer to deal with. We have:
> 
> struct uart_state;
> struct uart_info;
> struct uart_driver;
> 
> Every type of serial device would make use of struct uart_driver. Now
> struct uart_state and struct uart_info are heavly related to the TTY
> layer. So in the case of a TTY device was would have the void data field
> in struct uart_driver point to most likely struct uart_info.   

Uh oh, I really don't like this.  So we're going to have 'n' ports with
'n' struct uart_driver entries?  This sounds like needless bloat.

Please tell me you weren't seriously considering that!