On Wed, 23 Aug 2000 12:35:53 +0200, Daniel Phillips
<news-innominate.list.linux.kernel@innominate.de> wrote:
>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.
The 3270 hardware itself locks up when an AID (such as enter) key is
pressed. Some program has to send a control sequence to unlock the
keyboard. During the interval, an attempted to type will result in a
temporary lockup with a big X on the status line.
What you saw was probably the VM operating system. I was a VM hacker
in the good old days and the above was made possible by some kernel
(CP) level code which captured the input, queued it, and unlocked the
3270. The user space application was unaware of the situation.
[I am ignoring the case of VM dedicated devices for simplicity.]
This is completely unlike MVS, where the application controls the
world. In TSO, CICS, IMS, etc the terminal stays locked until the
application gets around to unlocking it. (@!%% MVS)
So the behavior you observed was from a kernel hack much like the
current Linux scheme.
john alvord
-
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