On Thu, Jan 24, 2002 at 05:32:57PM -0500, Greg A. Woods wrote:

 > > 	    any attempt to virtualize TTY instances should also attempt
 > > 	    to address this broader problem of picking the appropriate
 > > 	    default line discipline for a device.
 > 
 > In my fictional example it would be trivial to attach any upper-layer
 > driver to the low level UART driver -- be it a keyboard driver, a mouse
 > driver, or a TTY driver.  Calling it a line discipline is probably
 > misleading since that's only the old-fashioned way of dealing with
 > different ways to use a UART.

Old-fashioned (I can't believe that YOU, of all people, are calling
something that BSD has done ~forever "old-fashioned"), perhaps, but
damn useful.  Consider the case of PPP; you want to use the TTY line
discipline to talk to the modem to dial it, and then switch to the
PPP line discipline in order to perform PPP frame processing.

This is another reason I think the autoconfiguration machinery is not
the most ideal way to handle this.

(Actually, I think "properties" is a reasonable way to select the
*default* line discipline for a device -- if no "line-discipline"
property exists for a particular device, it can default to "tty").

 > Virtualised TTYs would not have to give up the concept of having special
 > line disciplines though.  One could still plug a serial mouse into any
 > serial port on a PC (or any machine) and use it as the system mouse
 > (assuming we had a generic line discipline for serial mice, and a pseudo
 > driver for it that could be attached to wsmouse or whatever).

Actually, this particular example should be done as is currently done,
that is to say "tty discipline, userland daemon reads mouse data, converts
it to wsevents, and injects those events into the appropriate wsmux".

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>