Serial driver problem query (v7 vs. System III/V)

[Guy Harris]

> It seems that where Version 7 always did either an output flush or a
> wait-until-output-has-drained before even asking the serial driver to
> perform functions like that, System III just goes ahead & does it. Thus
> does the USART get poked with information when it's busy outputting a
> character, and it gets upset and refuses to deal with us a anymore.  At
> 1200 baud, the `window of vulnerability' as Reagan would put it, was
> wider than at 9600, so while it happened to our modems all the time,
> we never saw the problem with our hardwired ports.

>From the System III manual page TTY(4):

	TCSETAW   Wait for the output to drain before setting the new
	          parameters.  *This form should be used when changing
	          parameters that will affect output.*

V7 had TIOCSETP and TIOCSETN; the former waited for output to finish, and
the latter didn't.  The difference is that the V7 manual mentions the one
that waits first, while the S3 manual mentions the one that doesn't wait
first, so one may pick the "right" one by default in V7 and the "wrong" one
by default in S3; the functionality is the same.  Note that boards like the
DZ11 and DH11 have two characters queued up even after it's gotten the last
one from the host, so they have to properly deal with speed changes of this
sort in the hardware.

> The other question that comes to mind is why did USG choose to eliminate
> the `ttyrend' interface for canonicalization of a buffer full of input?
> As you might guess, that would be perfect for our serial board.

USG didn't totally eliminate the "canonicalize a buffer of input" interface.
They changed it to assume (on the PDP-11 and VAX-11, anyway) that the most
common terminal interface would be a KMC-11 running a DZ-11, and that the
KMC-11 would do certain preprocessing - namely:

parity error checking
break checking (ignoring if IGNBRK, interrupting if BRKINT - try disabling your
	interrupt and quit characters but still permitting interrupts with
	the BREAK key on a vanilla non-USG system!)
stripping to 7 bits, if requested
XON/XOFF response - this should be done as soon as the XOFF comes out of the
	FIFO
INLCR processing (mapping of input \n to \r
IGNCR and ICRNL processing (mapping of \r to \n or discarding of \r)
IUCLC processing (mapping of A-Z into a-z)

The KMC-11 would then either pass the KMC/DZ driver a single character,
which would be passed to "ttin" as

	ttin(tp, <the character>, 1)

which means "here's a character, but the KMC-11 did all that extra stuff
already", or would have been given a "clist" block to fill in, and the
"clist" block would be passed to "ttin" as

	ttin(tp, <address of the clist block>, <number of characters
		in the clist block>)

As such, this isn't really intended as an Official Architecture for terminal
drivers; implementors of UNIX on a particular machine should feel free to
change the interface to routines like "ttin" and the "t_proc" routine to
fit their hardware.

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