Terminal output: parity, 7 vs. 8 bits, etc.

[Guy Harris]

> As I was paging through the tty driver looking at all of the
> horrible-ness of the code, I realize that the 7-bit input path is
> really a V6 hang-over and will require a monumental effort to expunge.
> Probably the tty driver should be completely rewritten, but I don't
> want to do it.

Exactly.  It did require a bit of effort to expunge, but Bell Labs did
it in System III.  The S3 tty driver (and its successors) was set up to
have orthogonal options for controlling the port.  For instance, there's
a flags word which specifies the baud rate, the character size (5, 6, 7,
or 8 bits), the number of stop bits (one or two), whether the receiver
is to be enabled or not, the handling of the parity bit, the "hang up
on last close" flag, and the "local" flag (ignore carrier - equivalent to
LNOHANG bit).  By and large, this means these bits get rearranged and
dumped directly into the multiplexer's control registers.  The stop bits
flag is sort of strange; I've always heard that 110 baud was the only baud rate
that used two stop bits, but it is consistent with the idea of letting the
process control the multiplexer as closely as possible.  On the other hand,
they decommissioned support of split baud rates, which is a bit INconsistent
with letting the process control the multiplexer as closely as possible -
admittedly, Bell doesn't like supporting the DH11 but they're still out
there.

With this scheme, you can have 7 bits plus parity, 8 bits plus no parity, or
8 bits plus parity, for instance.  A different flag bit in a different
flag word controls 1) whether the character received from the mux is to
be stripped down to 7 bits and 2) what is to be done with characters with
parity errors.

Unfortunately, the 8 bit output path isn't 100% pure.  They still stuff
things with the 8th bit on into the output clist to indicate delays; if
you turn the OPOST bit off, it tells the tty driver to ignore all output
transformations (tab expansion, delays, CR/LF stuff, etc.) and you then
get a real 8 bit path.

At one point I think the people at Berkeley considered picking up the
USG driver's "ioctl" interface; I suspect one could build a "old" and "new"
tty driver line discipline resembling vanilla and hacked USG UNIX rather
than vanilla and hacked V7.  I'm thinking of doing that for our 4.2BSD/S3
hybrid system at some point; I didn't like the vanilla V7 driver and don't
like the vanilla USG driver much better, and have gotten *very* used to
the BSD driver.  (We've already convinced the vanilla 4.1c driver to use
USG-style "clists".)

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy