^D on output to terminals

[utzoo!decvax!ucbvax!unix-wizards]

>From decvax!ittvax!swatt at Berkeley Mon Dec 14 14:17:43 1981

Steve Bellovin's remarks are applicable to more than one random device
hooked up to tty ports.  We have a 2780 protocol converter that accepts
^D from the asynchronous side to indicate (by gawd) end of
transmission, and turns the line around to allow input from the
synchronous side.  Now since this is a machine-machine communication
path, high speeds, and therefore flow control, are very desirable.

I have thought of several ways around this.  One is obviously to change
the mode of the driver for the instant it takes to send the ^D.  One is
as Steve Suggested, ~nother driver status bit.  The last one, which I
prefer, would be to have the driver check not for "EOT", but for
"tun.t_eofc" (or whatever the name is).  By accident or design the
driver does this now with the XON/XOFF characters ("tun.t_startc" and
"tun.t_stopc"), so if you change them, you change what the driver
expects/sends for flow control when in TANDEM mode.

I don't know which terminals actually do hang up on ^D, and if I did, I
would immediately add them to the list of un-favorite peripherals.  In
any case, the need for flow control and a transmission path for all 7
bit characters is clear.

BTW, has anybody extensively used the TANDEM mode while in normal
cooked (not RAW or CBREAK) mode.  The last time I tried it, there was a
subtle bug that cropped up if you sent relatively long average lines.

>From looking at the 4.1bsd drivers, it seems like the bug is still
there.  The following is a description of the problem and a SUGGESTED
fix. 

NB:	I have not installed or tested these changes.  I would be
	interested to hear if anyone can confirm or deny the existence
	of the problem, or could test out the suggested fix.  I get
	almost zilch in the way of kernel test time, so I won't get
	around to this one until it bites us.
		
		- Alan S. Watt (decvax!ittvax!swatt)

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
As they stand now, the tty drivers (old and new) can only safely
use TANDEM mode if also in either RAW or CBREAK mode.  The reason
is that the XOFF character is sent at interrupt time from ttyinput(),
but the XON character is sent from program level in canon().

The XOFF is triggered when the input queue is TTYHOG/2, and the XON is
sent when input drops below TTYHOG/5, where "TTYHOG" is 255.  If you
are in cooked mode and sending lines > 51 characters long, a hang will
occur if the XOFF is transmitted after 51 non-wakeup characters have
been transmitted on the current line and input is stopped before a
wakeup character is read.  Try receiving a bunch of 80 character lines
and you will for sure hang.

# enclosed fix:
: '/sys/dev/tty.c'
cp /sys/dev/tty.c /tmp/upd.$$.tmp ; chmod +w /tmp/upd.$$.tmp
ed - /tmp/upd.$$.tmp <<\!xxFUNNYxx
145c
/*
 * Block further input iff:
 * Current input > threshold AND input is available to user program
 */
#define CookedMode(X)	(((X)->t_flags&(RAW|CBREAK))==0)
#define InputReady(X)	((X)->t_delct>0 || !CookedMode(X))
	if (x >= TTYHOG/2 && InputReady(tp) ) {