Re: Serial design

[James S. <jsi...@tr...>]

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

True. The driver for the "touchscreen" does alot of things. 

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

I never said anything about sending AT commands. For example in
serial_8250_pci.c you have serial_pci_guess_board. Knowing that we have
a modem means we can only use a TTY interface for that port. Unless the 
device is hotpluggable. A input interface wouldn't make sense if we have
a modem. If it is possible to see what type of device we have we can use
that to determine what interface userland can have.

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

Okay. For the worst case we have the device map a struct uart_driver for
the TTY layer to every port.

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

Hm. I have no problem with that. As long as removing the flip buffers
don't break the other TTY drivers. 

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

I mean add functions to struct uart_driver to detect when a device has
been attached or detached depending if the hardware can support it.

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

No. A one to one mapping between struct uart_driver and a port.