Commit graph

3 commits

Author SHA1 Message Date
Victor Fusco
621a4d1a82 [PATCH] char/n_tty: fix sparse warnings (__nocast type)
Fix the sparse warning "implicit cast to nocast type"

Signed-off-by: Victor Fusco <victor@cetuc.puc-rio.br>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-10 10:06:26 -07:00
Roman Zippel
d6afe27bff [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>
2005-07-07 18:23:45 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00