On Tue, 22 Aug 2000, Roman Zippel wrote:
>
> The input line handling in n_tty.c should IMO not be done on interrupt
> level. AFAIK it's the only reason put_char can't sleep and you can get the
> input line handling with a simple (but admittingly not very realistic)
> example to overflow, because it has to echo chars back and at some point
> it simply has to drop characters.
The ECHO thing is the single worst thing in the whole UNIX tty handling.
If it wasn't for ECHO, tty's would be a lot simpler, and a lot saner.
The original Linux tty layer actually didn't echo. Echo was handled
entirely in the user context when the user did a "read()". It worked 99%
of the time, and some of the time it worked a lot better than the silly
UNIX echo semantics.
For example, the "echo in user context at read()-time" approach did the
right thing with passwords automatically - it would not end up echoing
stuff that was supposed to be hidden by mistake, the way a simplistic
"login" program will do (paging activity leading to ECHO clearing being
delayed -> fast typist sees the first few characters of the password end
up on the screen).
It also simplified the code a _lot_.
But eventually (very early on, in fact - I don't know if this was fixed
even before 0.01 was released, but I suspect not), Linux started doing
ECHO the traditional way, because of the 1% of the time when it didn't do
the right thing. People expect to see what they type even when nobody is
reading at the console. Too bad.
I'd love to go back to the "good old days", but I don't think it's an
option. Oh, well.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 21:00:08 EST