sasaki@harvard.ARPA (Marty Sasaki) (03/21/85)
There has been much discussion about whether a feature should be
implemented inside of the kernel or outside, in the form of library
routines. Most of the discussion has had to do with files and locking.
One thing that has always bugged me, is that terminal functions are in
the driver (which is in the kernel) on almost all of the systems that I
know about. The driver has all of this code in it that does things like
flow control, echo (if you have echo turned on), character translation,
line editing, etc.
Shouldn't the kernel part of a terminal driver be just two ring buffers,
one for input characters and one for output? The driver should just fill
and empty these buffers.
Then the user can link in whatever routines are necessary for the
particular application to do all of the rest. When I'm using a screen
text editor that turns off echo and puts the terminal in RAW mode, why
do I have to pay for the checks for echo and flow control and all of the
rest.
Does this bother anyone else?
--
----------------
Marty Sasaki net: sasaki@harvard.{arpa,uucp}
Havard University Science Center phone: 617-495-1270
One Oxford Street
Cambridge, MA 02138root@bu-cs.UUCP (Barry Shein) (03/22/85)
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
henry@utzoo.UUCP (Henry Spencer) (03/24/85)
> Shouldn't the kernel part of a terminal driver be just two ring buffers, > one for input characters and one for output? The driver should just fill > and empty these buffers. > > Then the user can link in whatever routines are necessary for the > particular application to do all of the rest. When I'm using a screen > text editor that turns off echo and puts the terminal in RAW mode, why > do I have to pay for the checks for echo and flow control and all of the > rest. Because if it isn't done in a central place, history shows that programmers don't bother providing it at all. Look at the wild chaos of different keyboard conventions in the old Xerox Alto software. Unix originally did not provide centralized "fancy" tty handling, and as a result one could seldom count on even something as simple as a backspace character. This got fixed long ago, fortunately. Mind you, I agree that much of that machinery shouldn't be imbedded down in the kernel, where it's very hard to fix problems with it. The trick is to move it out of the kernel while retaining the centralization, so that change is easy (and can be done on an individual basis) but all programs still get the full functionality by default. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jer@peora.UUCP (J. Eric Roskos) (03/27/85)
> Because if it isn't done in a central place, history shows programmers > don't bother doing it at all. To a certain extent, all the discussions over the past week or so about what should be "in the kernel" or not miss the point made by the above comment. There are only a handful of reasons for having something "in the kernel": 1) So it will be accessible to all users. This, of course, is what a central library of subroutines does, but putting it in the kernel encourages all the various compiler-writers to use it instead of inventing their own. 2) So all users will have to use it. This is a stronger form of (1), provided to force a stronger degree of uniformity. It fails when the facility "in the kernel" is not sufficiently general, or is so general that performance suffers. 3) So that it will have access to resources that are inaccessible to code "outside the kernel," e.g., privileged instructions, access to device control facilities, higher-priority execution, etc., in order to mediate and protect allocation of these resources to the code "outside". Only #3 above (of the items I've listed) HAS to be in the kernel, if the kernel is that portion of the code running on a machine that has access to restricted resources. There are other reasons related to (3) that make it beneficial to put the other two in the kernel on a particular machine -- for instance, the PDP-11 front ends on the PDP-10-based operating systems mentioned before (TOPS20; also TOPS10) are limited resources whose performance would be degraded if user processes were allowed to be loaded into them, eventhough you could conceivably allow ordinary users to download their TTY handling routines into them (assuming proper protection) -- but those are matters of optimization. -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Not that the story need be long; but that it will take a long time to make it short." -- H. D. Thoreau