Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site uvacs.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!mcnc!ncsu!uvacs!mac From: mac@uvacs.UUCP (Alex Colvin) Newsgroups: net.arch Subject: Re: smarter terminal device drivers Message-ID: <2048@uvacs.UUCP> Date: Wed, 24-Apr-85 18:13:49 EDT Article-I.D.: uvacs.2048 Posted: Wed Apr 24 18:13:49 1985 Date-Received: Sun, 28-Apr-85 06:08:34 EDT References: <327@piggy.UUCP> <101@daisy.UUCP> Organization: U.Va. CS dept. Charlottesville, VA Lines: 24 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"if