d6afe27bff
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> |
||
|---|---|---|
| .. | ||
| acorn | ||
| acpi | ||
| atm | ||
| base | ||
| block | ||
| bluetooth | ||
| cdrom | ||
| char | ||
| cpufreq | ||
| crypto | ||
| dio | ||
| eisa | ||
| fc4 | ||
| firmware | ||
| i2c | ||
| ide | ||
| ieee1394 | ||
| infiniband | ||
| input | ||
| isdn | ||
| macintosh | ||
| mca | ||
| md | ||
| media | ||
| message | ||
| misc | ||
| mmc | ||
| mtd | ||
| net | ||
| nubus | ||
| oprofile | ||
| parisc | ||
| parport | ||
| pci | ||
| pcmcia | ||
| pnp | ||
| s390 | ||
| sbus | ||
| scsi | ||
| serial | ||
| sh | ||
| sn | ||
| tc | ||
| telephony | ||
| usb | ||
| video | ||
| w1 | ||
| zorro | ||
| Kconfig | ||
| Makefile | ||