line disciplines considered inadequate

[utzoo!decvax!ucbvax!hpvax!sri-unix!sdcsvax!jmcg at Berkeley]

I think the implementation of tty devices under UNIX is seriously
flawed.  The question about line disciplines from MBM at MIT-XX points to
part of the problem, but I believe the difficulties lie even deeper.

There is a hierarchy of services provided by the system to support
files on disk devices (and, a bit ridiculously, on tapes) ranging from
the "raw" disk at the low level to "normal" file access, complete with
pathname parsing.  This hierarchy is pretty clean.

The services provided to support files on serial devices like RS232
ports are a hodgepodge.  Details such as the desired parity are handled
at the same level as tab expansion and terminal-dependent,
character-dependent delays.  There are many contributing causes for the
confused state of things: users demand a much larger variety of
services from `tty' files; the actual devices at the other end of the
line can be another computer, a human being, a line printer, plotter,
etc.; terminal manufacturers have been marvelously inventive.

The approach to a solution that I would like to see can be termed
"stackable line disciplines"--this concept was mentioned by Bill Joy
several Usenixes ago.  I don't know how they would be controlled, how
to get around the performance problems, etc., but it would work
something like this:

At the lowest level you would have the "raw" device file.  The user
would typically NOT open this device any more than he typically opens a
raw disk device.  The raw device provides for characters to move in and
out plus a hook which would allow a "term" file to be attached to the
device.

A "term" file would still act pretty much the way "tty"s do now.  What would
be different is the kernel's implementation.  There would typically be
a list of line disciplines associated with the tty and each line
discipline would get a whack at the data.  I envision these line
disciplines as being very simple.  Some examples: an echo discipline
would arrange for the character to be echoed, a delay discipline would
check outgoing characters to see if a delay was required, a delimiter
discipline would check an incoming character to see if it requires some
action (CR, INT, erase, kill, etc), and a possibly separate discipline
will look up the action bound to that character and perform it.  At the
bottom of it all would be the "attach" discipline which would deliver
characters between the "raw" file and the "term" file.

I think this approach has lots of advantages.  Implementing virtual
terminals should be easier.  Whatever MPX files are good for, their
discipline could be inserted into the stack.  It should be possible to
create disciplines with actions implemented as functions in a user
process (an EMACS discipline?).

						Jim McGinness
						ucbvax!sdcsvax!jmcg
						UC San Diego--Chemistry