The EXTPROC flag originated from AT&T's tty driver for the VAX-11, because
they were fond of using DZ-11 serial interfaces (interrupt per character,
coming or going!) along with a KMC-11 (a secondary processor on the UniBus
to handle all those interrupts, and offload the main processor), instead of
the DH-11 (interrupt per character input, with a decent sized silo, and DMA
output for strings) that was popular with 4BSD UNIX users.

In essence, AT&T dropped most of the tty driver into the KMC-11, told it to
handle the DZ-11's, and then set the EXTPROC flag, which meant that the
characters that the kernel was getting from the KMC-11/DZ-11 combination
had already been canonicalized (or whatever else was necessary) and can be
passed through directly to the userland program without further processing.

Later, the V7/4BSD tty interface and the System V termios were merged by
lots of people trying to get to just one API. There are days when I wish
we'd adopted dmr's streams (not to be confused by the AT&T STREAMS
networking API crapola), instead; it has some very useful properties
(consider how many context switches a single keystroke causes when received
over the Internet in a telnet or rlogin or ssh session - those all go away
with streams).

Modern telnetd sets EXTPROC for linemode for the same reason as AT&T did
for the KMC-11/DZ-11 combo: the presumption is that whatever tty
canonicalization/processing that needs to be done was done by the TELNET
client at the remote, and that the bytes can be passed straight through the
high level tty interface to userland program(s). The implication of this is
that any TELNET client which wants to do line mode needs to implement a
full tty driver, or take advantage of one that the OS provides. Otherwise
the results will likely be ugly for the user.

Single character processing is expensive, both in the kernel and in
overhead on the Internet; we'd all be better off if we could make line mode
work reasonably everywhere...

	Erik <fair@clock.org>