Messages in this thread | | | Date | Mon, 16 Feb 2015 13:30:32 -0500 | From | Peter Hurley <> | Subject | Re: [PATCH 1/1] pty: BREAK for pseudoterminals |
| |
On 02/16/2015 12:16 PM, Petr Tesarik wrote: > On Mon, 16 Feb 2015 11:24:16 -0500 > Peter Hurley <peter@hurleysoftware.com> wrote: > >> Hi Petr, >> >> On 02/16/2015 08:22 AM, Petr Tesarik wrote: >>> On Mon, 16 Feb 2015 08:04:02 -0500 >>> Peter Hurley <peter@hurleysoftware.com> wrote: >>> >>>> On 02/05/2015 02:11 PM, Nan Li wrote: >>>>> This will greatly enhance the usefulness of QEMU virtual serial ports, because the Linux kernel interprets a break on the serial console as a SysRq, but there is currently no way to pass this signal over a pseudo-terminal. This patch will work for transmitting BREAK from master to slave through pseudo-terminal. >>>> >>>> pty is an IPC mechanism, not a virtualization driver. >>> >>> No, but it can be used as a TTY. Teletypes have always had the capacity >>> to send and receive BREAK. >> >> In some general-purpose but restricted capacity, the *slave* end _mimics_ >> a tty. That doesn't mean that it is suitable for every conceivable >> use as a tty, nor should it. > > Unless there's some specification of what should and what should not be > implemented, this question is open for discussion, methinks.
This question is open for discussion regardless of specifications. I thought that's what these emails were. :)
FWIW, here's the relevant excerpt from SUSv4 regarding tcsendbreak():
"If the terminal is not using asynchronous serial data transmission, it is implementation-defined whether tcsendbreak() sends data to generate a break condition or returns without taking any action."
>> If BREAK was actually useful for real terminal i/o, the pty driver >> would already support this. > > If I strictly followed this statement, no improvement would ever be > possible. Or did I miss something? Are Linux PTYs a legacy subsystem > that never gets any new features?
I'm not opposed to new features, but I do think that new kernel features should only address those requirements which cannot be met in userspace (whether that's functionality or performance or whatever the requirements).
>> [...] >>> Well, the default termios includes IGNBRK, so unless they bothered >>> to do anything about BREAKs, they won't see any change. >> >> Userspace programs are sloppy, especially with terminal i/o and >> settings. Unlikely is not the same as not possible. > > Sure. New features may break sloppy programs. OTOH, the obvious > workaround is not using such programs together with new programs that > actually use tcsendbreak() for something... until those sloppy programs > are fixed. It's not like the whole system stops working once this patch > is applied.
Userspace breakage is not an acceptable outcome, even if the program is provably buggy (other than for security-related issues).
>>> Anyway, the current kernel behaviour is clearly suboptimal. Calling >>> tcsendbreak() on a pty descriptor does nothing but reports success. >>> There are obviously two ways to fix it: either report an error, or >>> deliver the BREAK for real. >> >> The pty master end is even less of a tty than the slave end, but this >> isn't really about errno. This patch doesn't address either of your >> points wrt tcsendbreak() on the slave descriptor which is the actual >> terminal end. > > That's a valid point. And, indeed, the terminal end actually needs the > handling of BREAK to make it useful.
There's two problems with adding this to the slave end:
1. The master pty termios is not programmable, so it can't set IGNBRK. 2. It creates a security maintenance burden because the unprivileged slave pty end must not be allowed to terminate the privileged master end, such as accidentally via BRKINT.
>>> This patch implements the latter, adding at least one valid use case >>> to explain why it is better than the former. >> >> I disagree that this is a valid use case for the _pty driver_. >> >> AFAICT this is simply for convenience, as sysrq functionality is >> already available via sendkey. > > That's a completely different story. This patch (after fixing it to > work with the terminal end) would allow me to set up a QEMU emulated > serial port using a pty (i.e. "-chardev pty") and send a BREAK signal > to it, no matter what is running in the guest.
> I mean, I can run an emulated MIPS64 as a QEMU guest on an x86_64 host, > and still somehow pass SysRq to it. IIUC this will never be possible > with KVP.
> Another use case: In my job, I'm struggling with different serial > consoles (some using ipmi SoL, some using telnet to a service > processor, some connected with a real RS-232 link). If I could send > BREAK over a pty, I could extend ipmiconsole to translate it to the SOL > message, telnet to translate it to the telnet escape, amtterm to send a > corresponding message... Then I could send a BREAK to any of my systems > simply by pressing 'C-A b' in screen(1) without having to think how is > this particular machine connected and what the correct sequence is for > that protocol. > > Just my two cents, > Petr Tesarik >
| |