Where Goeth the Line-editing?

[der Mouse]

In article <805 at dms.UUCP>, shepperd at dms.UUCP (Dave Shepperd) writes:
> From article <7564 at cbmvax.UUCP>, by ag at 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 at larry.mcrcim.mcgill.edu