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

[Petr Tesarik]

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.

> 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?

>[...]
> > 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.

> > 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.

> > 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/