lkml.org 
[lkml]   [2015]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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
    >



    \
     
     \ /
      Last update: 2015-02-16 19:41    [W:3.446 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site