Subject: Re: TTY virtualization driver
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Greg A. Woods <email@example.com>
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; <firstname.lastname@example.org>; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>