4.2 BSD Signals: A Proposal (actually, tty drivers)

Guy Harris guy at rlgvax.UUCP
Sun Jan 22 10:53:27 AEST 1984


> If you "re-Berkeleyize" the USG tty driver, any additional ioctl should
> work in the spirit of the USG ioctl's, and let you set *all* the flag
> words/special characters with a single ioctl.  I thought part of the
> reason for all them ioctl's in the 4BSD tty driver (actually from
> IIASA) was leftover from V6 days when the stty/gtty entry point was
> passed *exactly* three int's (or six char's) from user space, and this
> was carried over as a superstition.

The multiple "ioctl"s to set the terminal modes in 4BSD comes from V7, where
they also had multiple "ioctl"s.  I suspect the reason was that the V7 driver
was done, it was done by adding stuff to the V6 driver which did have to
use only what the "stty/gtty" routines could handle, so instead of redoing the
"ioctl" interface entirely they added new "ioctl"s, and Berkeley continued
the tradition for compatibility (i.e., "stty/gtty" and the old "ioctl"s still
worked).  The people who did the 3.0 driver probably decided that, instead of
taking the V6-like 2.0 driver and adding all the V7 "ioctl"s, they'd redo the
whole thing right.  In 4.1cBSD there was sort of a half-assed attempt at
redoing the "ioctl"s - they added an "ioctl" to set the "sg_flags" and local
flags words as one "long", and an "ioctl" to set all the special characters,
but one still had to use the old "ioctl" to get/set the speeds - but that was
backed out in 4.2BSD.

My only concerns about extending TCGETA/TCSETA to include more special
characters and flag bits would be:

1) Adding the flag bits to existing words might conflict with future extensions
from Bell; adding a new word would be safe but slightly ugly (for instance, the
"echo control characters as ^x" bit belongs in c_lflag but Bell may eventually
use all 16 bits of that "short").

2) Programs which do a TCSETA without first doing a TCGETA on the standard
input/output/error deserve to break (the *only* right way to set the modes
on a port whose modes have already been initialized is to read the current
modes, change the "termio" structure, and set the modes), but some programs
which do the first open on a line and set the modes directly (communication
programs, for instance) might break because they set the new mode bits and
control characters to zero without realizing that this may have an undesired
effect.  By and large, setting the bits to zero would be harmless, as leaving
those bits off leaves the driver behaving like the standard USG tty driver,
but setting the control characters to zero doesn't disable them.  The latter
is actually a misfeature of the driver to some degree; for example, "getty"
under System III sets your "break" or "eol" character (V7 calls it the "break"
character and USG UNIX calls it the "eol" character) to NUL (zero) rather than
'\377'.  The latter was guaranteed to disable the control character in V7,
as the character was masked down to 7 bits before it was compared against the
special characters, but may not do so in USG UNIX as the stripping of the
eighth bit is an option which can be set independently of most other options
(this is useful, for instance, if you have a terminal with a META key which
turns the eighth bit on; you can use the META key without all the disadvantages,
like disabling XON/XOFF, of the V7 "raw" mode).  The UNIX 2.0 backward
compatibility "ioctl" TIOCSETP (which several people may have made backward
compatible with V7 instead) sets the EOL (and the S5 EOL2) characters to
0, also.

I would vote for changing the USG driver to consider NUL not to ever be the
erase, kill, interrupt, quit, EOF, EOL, EOL2, etc. character, so that
setting that character in the "termio" structure to NUL would be the official
way to disable them.  This would mean that most (if not all) programs which
initialized a terminal port would not enable those characters if what the
program did was fill in a structure and do a TCSETA without first doing a
TCGETA.  Under these circumstances, changing the shape of "struct termio"
would only break binary images of programs, and if that was really a problem
TCSETA, etc. could be given different "ioctl" numbers and the old ones could
be left around for backwards compatibility.

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



More information about the Comp.unix.wizards mailing list