]> www.pilppa.org Git - linux-2.6-omap-h63xx.git/commit
[PATCH] tty output lossage fix
authorRoman Zippel <zippel@linux-m68k.org>
Fri, 8 Jul 2005 00:56:55 +0000 (17:56 -0700)
committerLinus Torvalds <torvalds@g5.osdl.org>
Fri, 8 Jul 2005 01:23:45 +0000 (18:23 -0700)
commitd6afe27bfff30fbec2cca6ad5626c22f4094d770
tree83c28d2c90fe720b5a315b89301cf3a519ffed88
parent8759145114f72857bcaeed338db21620a6619b26
[PATCH] tty output lossage fix

The patch fixes a few corner cases around tty line editing with
very long input lines:

- n_tty_receive_char(): don't simply drop eol characters,
  otherwise canon_data isn't increased and the reader isn't woken
  up.

- n_tty_receive_room(): If there is no newline pending and the
  edit buffer is full, allow only a single character to be written
  (until eol is found and the line is flushed), so characters from
  the next line aren't dropped.

- write_chan(): if an incomplete line was written, continue
  writing until write() returns 0, otherwise it might not write
  the eol character to flush the line and the writer goes to sleep
  without ever being woken up.

BTW the core problem is that part of this should be handled in the
receive_buf path, but for this it has to return the number of
written characters, as the amount of written characters may not be
the same as the amount of characters going into the write buffer,
so the receive_room() usage in pty_write() is not really reliable.

Alan said:

The problem looks valid. The behaviour of 'traditional unix' appears to
be the following

If you exceed the line limit then beep and drop the character
Always allow EOL to complete a canonical line input
Always do signal/control processing if enabled

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
drivers/char/n_tty.c