Subject: Re: TTY virtualization driver
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Greg A. Woods <>
List: tech-kern
Date: 01/24/2002 19:16:17
[ On Thursday, January 24, 2002 at 14:54:39 (-0800), Jason R Thorpe wrote: ]
> Subject: Re: TTY virtualization driver
> 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.

Well, "old-fashioned" certainly takes on different connotations in the
context of Ritchie's idea of "streams" and the far more recent
implementations of it in prevalent use!  ;-)

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

Sure -- of course -- which is why I also mention "streams"!  ;-)

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

I don't see how a virtual TTY upper-layer driver will affect the way the
PPP line discipline works.  It should "just work" as it does today -- no
change.  I wouldn't really want to remove the current "line discipline"
machinery with a common TTY driver.

It's been a couple of years since I looked in detail at the com driver,
but as I recall it wouldn't be that hard to split it out into a chip
layer and have the TTY stuff, including TIOCSLINEDD (and TIOCSETD) and
related handling, done by an upper-layer driver.  Something like zstty
and zsc/zs are now.  The trick is defining the middle layer driver API
so that would be sufficient for the known UART drivers, and then
adapting them to implement it.  :-)

> (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").

As far as I can tell the default line discipline for all tty-like
devices is always "termios".

								Greg A. Woods

+1 416 218-0098;  <>;  <>;  <>
Planix, Inc. <>; VE3TCP; Secrets of the Weird <>