Linus Torvalds wrote:
>
> 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.
Why not? The current approach to echoing is inherently wrong - it's
just a hack that happens to produce acceptable results much of the
time. The problem is that the low-level serial input driver is trying
to do something that should properly be done by the display device.
To illustrate, I'll go back - way back - to the only device I've ever
used where this worked properly: an IBM 3270 series terminal. On a
3270, if you type when the system isn't ready for you, your input still
appears on the screen - in a line overlaid on top of the regular
display. When you hit enter the line disappears and you can enter
another one. When the system (a mainframe) finally gets around to you
it queries the terminal controller for input, which alerts the 3270 to
the fact that the typeahead window should now go away and be replaced by
the underlying text. Presumeably your input is then echoed in a form
chosen by the application.
This approach is correct for a number of reasons. The first that comes
to mind is that your typahead doesn't mess up the normal screen output -
when you scroll back you don't have to make allowance for the
possibility that some text actually came from your fingers, not the
process. Another big advantage is the one that you touched on - a task
that should not be done by the serial input driver is taken away from it
and put in the proper place.
Where is the proper place? It's in the display device driver. In the
case of the 3270, the display device is a big clunky old terminal. In
the case of an X-console it's a graphics window, and we could use a
fancy popup to show the typeahead, something like the Alt-Tab popup used
by KDE. It's only in the case of the good old text console that things
get confusing, because it just looks so darn simple to handle the echo
in the same part of the code that handles other output.
This is the wrong thing to do. The correct thing is to bite the bullet
and implement a smarter display device that can handle the
appearing/disappearing input text window in much the same way as the old
3270's. Not all *that* much work when you think about it. This moves
the echo code out of the serial input driver and into the display
driver, where it should be.
The problem of keeping password text hidden in the case of a fast typist
at logon time is handled simply: don't enable the device echo handling
until the login process is ready to accept input.
-- Daniel - 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