Re: Serial design

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

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

Sorry. My mailer has troubles with placing text files in the body of a
email.

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

   Hm. That depends on the hardware and/or hardware setup. For example on
the iPAQ one serial port is used just for the touchscreen. The other for
IR 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. 
   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. 

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

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. Also maybe a shutdown or
connect function?
 
> >    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.

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.