8 bit I/O vs 4BSD

[Chris Torek]

I think everyone realizes that if you are going to preempt characters
for flow control, they aren't going to be available for data.  You
*can* have an 8 bit data path in *both* directions *and* have flow
control; you just have to give up at least one character (it can still
be sent by using some kind of protocol, of course).

However, the Berkeley tty drivers just don't allow it.  Here's what
goes wrong, at least, what I can think of easily (I haven't tried to
implement 8 bits myself): (1) delays can't be done by meta characters
[this is a problem with LITOUT mode too!]; (2) what if you want the
input character '\377' as a special character?; (3) how do you tell how
many bits should be used to check for special characters; i.e., is
meta-^S a stop character or not?; (4) You have to change every single
da[rm]ned device driver to do things differently because of (1-3).

Speaking of flow control, has anyone ever thought about how much
problems using in-band data for this has caused?  If terminals had
hardware flow control, we might not have kludges like the pty driver
sending special packets whenever t_startc and t_stopc change from/to
^Q/^S, and rlogind flushing perfectly good data just to get that OOB
data, and . . . [froth froth].  Have you ever noticed that the pty
driver *doesn't* send any messages about any other state changes (like
raw mode?) [rant rant].  You'd think that if Berkeley saw fit to
provide info about changes in local flow control on a network port to
the program doing the connecting, they'd also see fit to provide nice
ways to get the entire state across, not just one tiny bit [rave
rave].  I'd better stop, I'm getting out of hand here.  Maybe I should
add net.flame.... :-)
-- 
(This line accidently left nonblank.)

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at maryland