Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site bu-cs.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!genrad!mit-eddie!godot!harvard!bu-cs!root
From: root@bu-cs.UUCP (Barry Shein)
Newsgroups: net.arch
Subject: Re: inside the OS vs. outside the OS
Message-ID: <293@bu-cs.UUCP>
Date: Thu, 21-Mar-85 20:25:26 EST
Article-I.D.: bu-cs.293
Posted: Thu Mar 21 20:25:26 1985
Date-Received: Sun, 24-Mar-85 04:45:54 EST
References: <501@harvard.ARPA>
Organization: Boston Univ Comp. Sci.
Lines: 47

Although feasible and quite doable the problem with putting
the terminal drivers in the user process space has to do
largely with response. To do echoing on a keystroke basis
for full-duplex systems your process would have to be
woken up, possibly swapped/paged in, on every keystroke.
This in fact is exactly what happens when in a RAW mode
and can really thrash a system. At least if echoing etc 
is being done in the kernel those users in cooked mode
don't need to have their processes woken until they hit
a terminator (say CR.)

Ok, so propose that we make a tty library and make it
global sharable...well, doesn't win much, if you take
control you defeat it otherwise you are kind of back
where you started, no?

More interesting approaches:

	1. TOPS-20: Use PDP-11 front ends to do
	a lot of the mundane terminal handling.

	2. Extend that thought, make your terminal
	handler entirely table driven and pass the
	tables to an intelligent workstation for
	local processing.

	3. Extend that thought, put up a network file
	system that supports things like changing your
	default directory to the remote host and do
	the editing/full-screen applications entirely
	in your local work station (we currently do
	this at BU using LEAF protocols on UNIX to
	support our XEROX lisp machines.) I assume
	that the SUN NFS will also support this.

	4. IBM (real, not PCs): either make your users
	use half-duplex (ugh) or build exotic 327x
	terminals with local terminal handlers that
	only transmit entire screens (or a change list)
	when an ENTER is hit, support local editing of
	the screen (a la atari.)

I guess the question is: What problem are you really trying
to solve? You only seem to say that the current state of
things 'burns you up'.

	-Barry Shein, Boston University