On 01/19/2015 02:43 PM, Howard Chu wrote: > Peter Hurley wrote: >> On 01/19/2015 11:36 AM, Howard Chu wrote: >>> Peter Hurley wrote: >>>> On 01/19/2015 07:46 AM, Howard Chu wrote: >>>>> Peter Hurley wrote:
[...] >>>> Which brings up another point: only a pty master should be able to set >>>> EXTPROC >>>> mode. Right now, any tty can be set to EXTPROC and the pty slave can even >>>> accidentally unset it. This argues for a new pty ioctl() to set EXTPROC in >>>> termios. pty_set_termios() can silently merge the bit. >>> >>> Historically EXTPROC could also be set on regular ttys, for lines that were >>> hooked up to special terminal interfaces. E.g. X.29 PADs that did their own >>> input processing. I'm not sure how relevant this is now, but this is the >>> reason EXTPROC is not a pty-specific ioctl. >> >> How does the remote end find out when non-canon mode is selected? >> And who does the EXTPROC setting, because if it's the program that opened the >> tty, then it can just select raw mode instead. > > There's a few significant differences in semantics between raw mode and > EXTPROC mode. Sorry, I have this unfortunate habit of referring to non-canonical modes as 'raw' (which stems from the way the terminal driver handles input). > The point of EXTPROC is to maintain the tty driver state as if cooked mode > were still in effect. One obvious difference is that VMIN/VTIME are overlaid > on VEOL/VEOF in raw mode Not in Linux; these are different c_cc[] slots. > , so the two are not directly interchangeable. > > The fact that EXTPROC can be manually unset is by design. Quoting from the > original again: > >> stty.diff: >> This file contains the changes needed for the stty(1) program >> to report on the current status of the TS_EXTPROC bit. It also >> allows the user to turn on/off the TS_EXTPROC bit. This is useful >> because it allows the user to say "stty -extproc", and the >> LINEMODE option will be automatically disabled, and saying "stty >> extproc" will re-enable the LINEMODE option. This option is not supported by gnu coreutils. So it's really back to the question of, does allowing EXTPROC for regular ttys have _value_? >>>>>> 6. EXTPROC still does some input processing on the server. For example, >>>>>> 7-bit mode (ISTRIP), tolower mode (IUCLC) and processing while >>>>>> closing; if input processing is being done on the local/client >>>>>> side, >>>>>> why the extra work here? >>>>> >>>>> That's defensive, on the assumption that something else might break if >>>>> e.g. the tty expected only 7-bit input but 8-bit characters were sent to >>>>> it. >>>> >>>> Ok, is that because RFC 1116 doesn't specify ISTRIP and IUCLC handling so >>>> the server can't be sure the client did it? If so, that should be >>>> documented >>>> so that refactors don't remove that handling. >> >> Could you get back to me about this, as well? > > The telnet protocol (RFC854) defines a Network Virtual Terminal (NVT) as > using 7-bit USASCII in an 8-bit field. As such, it expects the client to be > able to generate both upper and lower case itself, so there's no analogue to > IUCLC, and there would be no reason to use ISTRIP. > > RFC5198 updates the protocols to use UTF8. So again, it assumes full octets > are being transmitted. > > Perhaps we can drop these special cases from the driver. I don't mind leaving it in, but without comments it looks like a refactoring error. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
