ag@cbmvax.UUCP (Keith Gabryelski) (08/08/89)
To comp.unix.wizards since it seems more appropriate. In article <795@dms.UUCP> shepperd@dms.UUCP (Dave Shepperd) writes: >From article <13303@bloom-beacon.MIT.EDU>, by jik@athena.mit.edu (Jonathan I. Kamens): >> In multics, it was possible to install a driver that lived at the >> gateway between the actual terminal and user processes. This driver >> would intercept and process *all* input before sending it to the >> process. Therefore, if you wrote a line-editing driver and installed >> it, it would work for *every* program on the system, without fail. >> There were, of course, ways to turn off the line-editing features for >> programs that needed character-by-character input. >> > >Actually, Un*x has this "feature" as well. At least, sort of. The >concept of line disciplines was developed to address this issue (or >other protocol handling requirements). Line discipline 0 is responsible >for doing the input editing you get when doing normal (such as echo, >backspace processing, line kill, signals, etc). It also does the stuff >such as adding extra cr's, lf's, null's or other things in the output >stream as so indicated by various stty flags. Line disciplines don't do >the job as neatly as is desired (a better idea, STREAMS, was invented >which does the job quite a bit better). We actually just wrote a line discipline that emulates the TOPS-20 line discipline for our SYSV3.2 port to the Amiga (echoing only when input was read), ^O, ^V, ^W, and no backspacing over your prompt. I was going to add history and real command line editting, but finally came to my senses that the kernel was just not the place for such a user-configurable/messy thing. The best suggestion I've heard is a daemon the user runs that gets handed each character the user types and deals with them and the canon buffer appropriately. I did finally break down and added a last command hack but am sure this will disappear when something better is found. I am open to suggestions. Pax, Keith
shepperd@dms.UUCP (Dave Shepperd) (08/09/89)
From article <7564@cbmvax.UUCP>, by ag@cbmvax.UUCP (Keith Gabryelski): > > We actually just wrote a line discipline that emulates the TOPS-20 > line discipline for our SYSV3.2 port to the Amiga (echoing only when > input was read), ^O, ^V, ^W, and no backspacing over your prompt. > > I was going to add history and real command line editting, but finally > came to my senses that the kernel was just not the place for such a > user-configurable/messy thing. > I agree that putting the editor in kernel code is ugly, however, since there doesn't seem to be any better way to do it without bringing the system to its knees, and IMHO line editing is absolutely required, it has to be there. Until somebody cooks up something better (like everybody starts using STREAMS), I'm going to keep using my kernel code line editor. > The best suggestion I've heard is a daemon the user runs that gets > handed each character the user types and deals with them > and the canon buffer appropriately. > Don't forget that the daemon would have to get all the output text too. During development of my discipline I noticed that many utilities do single character output to the terminal. I believe the poor system would really slow down if all terminal I/O had to be routed through another usermode task. -- Dave Shepperd. shepperd@dms.UUCP or motcsd!dms!shepperd Atari Games Corporation, 675 Sycamore Drive, Milpitas CA 95035. (Arcade Video Game Manufacturer, NOT Atari Corp. ST manufacturer).
guy@auspex.auspex.com (Guy Harris) (08/10/89)
>I agree that putting the editor in kernel code is ugly, however, >since there doesn't seem to be any better way to do it without >bringing the system to its knees, and IMHO line editing is >absolutely required, it has to be there. Until somebody cooks >up something better (like everybody starts using STREAMS), >I'm going to keep using my kernel code line editor. And even once everybody starts using STREAMS, you'll *still* keep it (although modified for STREAMS), since streams modules run in the kernel. However, don't assume that there "isn't any better way to do it without bringing the system to its knees" before trying one of the other ways; try snarfing Ken Almquist's "atty", for instance, if you have BSD-flavored pseudo-ttys.
mouse@mcgill-vision.UUCP (der Mouse) (08/18/89)
In article <805@dms.UUCP>, shepperd@dms.UUCP (Dave Shepperd) writes: > From article <7564@cbmvax.UUCP>, by ag@cbmvax.UUCP (Keith Gabryelski): >> [stuff about command-line in the kernel] > I agree that putting the editor in kernel code is ugly, however, > since there doesn't seem to be any better way to do it without > bringing the system to its knees, Why does everyone keep saying this? Doing this at the user level does not *necessarily* bring the system to its knees. (You managed to push one of my buttons.) There are systems where it will, yes. But there are many systems where it won't. On one system I use regularly, for example, here's what happens when I type a simple character like x: - Two interrupts, each one involving waking up a user process (one each for pressing and releasing the key) - Switch back to kernel mode (write on a socket) - Switch back to user mode, different process (read the socket) - Kernel mode (write on a pty) - User mode, process #3 (read the pty) - Kernel mode (write echo to pty) [see below] - User mode, process #2 (read pty) - Switch back to kernel mode (write on the socket) - Back to user mode, process #1 (read the socket) - Finally see the x appear on my screen. The system in question is a Sun running X. I can now rlogin from that window. This adds more switches and two trips over the Ethernet. Funny, but performance is still just fine, thank'eeverymuch. ["see below": At least 90% of my keystrokes are typed to things that use cbreak+noecho mode, so yes, there is a trip to user mode here.] > I believe the poor system would really slow down if all terminal I/O > had to be routed through another usermode task. There are lots of counterexamples. Where did you acquire this belief? There are, undoubtedly, many systems where this is true. It is *not* universally true. And as CPUs get faster compared to humans, it is becoming less and less worth worrying about, IM(ns)HO. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu