Re: [PATCH 1/1] pty: BREAK for pseudoterminals

[Peter Hurley]

On 02/16/2015 12:16 PM, Petr Tesarik wrote:
> On Mon, 16 Feb 2015 11:24:16 -0500
> Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> 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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/