mac@uvacs.UUCP (Alex Colvin) (04/25/85)
The suggestion of (101@daisy) to have the tty driver automatically switch break
tables isn't just a useful generalization. It's necessary to make the break
tables work. Everyone seems to assume that the process can be scheduled, run,
process the input, and make a system call with a new break table, before the
next character arrives. This works fine on small machines with slow input, but
even UN*X falls down here when the load is heavy.
Allowing user programs to provide the break tables and transition rules is
fairly elegant, and amounts to allowing them to program the input drivers.
However, allowing user programs to hang arbitrary subroutines onto operating
system hooks (in LISP terminology) isn't always a good idea. On time-sharing
systems this creates headaches for security. Here we are also assuming that the
tty driver is executing on the same machine.
On *my* company's operating system we had a separate computer ("front end")
running the tty drivers. No overlap in address space, not even a common
instruction set. Furthermore, during the system's evolution at least four
different machine architectures were used for front ends. It was suggested that
we provide a secure, common, interpreted instruction set for user-written tty
interfaces. The solution adopted at Dartmouth was to do this in a micro stuffed
into the terminal itself.
mac the na"ifjack@boring.UUCP (05/01/85)
Providing multiple break/echo tables and transition rules
isn't necesary if you delay echoing etc. until the character
is being read.
This doesn't mean that you have to wait until it is transferred
to user space, only until the user program has done a read.
Scenario :
User Kernel User program.
Type A Store it.
Type B Store it.
Read 80 chars, terminate on ' '
Echo A and B
Type C Echo C and store it.
Type ' ' Store ' ' and echo it.
Copy 'ABC ' to user space.
Wake user up.
Note that it is debatable whether the space should be echoed.
I think that it should, since the user program can make provisions
not to echo it (assuming there are both an 'echo map' and a 'break map'.
I think that delayed echo is usually a neat feature, since you
can't mess up your screen by typing ahead to a program that
doesn't expect it, and that it will easy the implementation
of a break- and echo-map.
--
Jack Jansen, {decvax|philabs|seismo}!mcvax!jack
The shell is my oyster.hmm@unido.UUCP (05/02/85)
A minor problem with the invisible type-ahead: You cannot easily correct errors you made when typing ahead. Maybe there should be a possibility to turn this off, i.e, make it echo when the character is typed. Hans-Martin Mosner Universitaet Dortmund (Germany) ihnp4!hpfcla!hpbbn!unido!hmm seismo!mcvax!unido!hmm