On Tue, 30 Jan 2001, Edmund GRIMLEY EVANS wrote:
> ...So the line-buffering has to happen on the other
> side of the "read" system call.
Correct.
> Of course, this doesn't really mean that line-buffering has to be in
> the kernel. It could be handled by a server...
Indeed so. Note that if you are getting into your system via telnet, or
ssh, or for that matter X, then your keystrokes *are* going through a
non-trivial server already, and it would not be conceptually difficult to
move the terminal-emulation stuff out of the kernel entirely and into the
servers.
("Terminal emulation"? Yes! If you look at the obsolete arcana of the
terminal interface -- things like the newline delays and the oldest of the
character translations -- it's essentially emulating a standard virtual
hardcopy terminal, on top of any of the actual hardcopy terminals in
common use within Bell Labs circa 1975. This would be a lot more obvious
if anybody had ever gotten around to updating it to know about terminals
with screens...)
(Oh, and the reason why it's done in the *kernel* is that in the early
days, only one user program fit in memory (together with the kernel) at a
time. Things like keystroke handling had to be done in the kernel, to
preserve any semblance of timely response.)
Henry Spencer
[EMAIL PROTECTED]
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
