Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933053AbbBPNWs (ORCPT ); Mon, 16 Feb 2015 08:22:48 -0500 Received: from cantor2.suse.de ([195.135.220.15]:53562 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932697AbbBPNWr (ORCPT ); Mon, 16 Feb 2015 08:22:47 -0500 Date: Mon, 16 Feb 2015 14:22:44 +0100 From: Petr Tesarik To: Peter Hurley Cc: Nan Li , gregkh@linuxfoundation.org, jslaby@suse.cz, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] pty: BREAK for pseudoterminals Message-ID: <20150216142244.33378c18@hananiah.suse.cz> In-Reply-To: <54E1EAC2.6020906@hurleysoftware.com> References: <1423163489-26538-1-git-send-email-nli@suse.com> <54E1EAC2.6020906@hurleysoftware.com> Organization: SUSE Linux, s.r.o. X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3146 Lines: 88 On Mon, 16 Feb 2015 08:04:02 -0500 Peter Hurley 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. > Those programs that know they're consuming from a slave pty may not > have bothered to set termios for BREAKs, and may not be prepared > for NULLs in the input stream. Well, the default termios includes IGNBRK, so unless they bothered to do anything about BREAKs, they won't see any change. 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. This patch implements the latter, adding at least one valid use case to explain why it is better than the former. Regards, Petr Tesarik > > Signed-off-by: Nan Li > > --- > > drivers/tty/pty.c | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c > > index e72ee62..ac8893a 100644 > > --- a/drivers/tty/pty.c > > +++ b/drivers/tty/pty.c > > @@ -31,6 +31,7 @@ > > static struct tty_driver *ptm_driver; > > static struct tty_driver *pts_driver; > > static DEFINE_MUTEX(devpts_mutex); > > +#define BREAK_STRING '\0' > > #endif > > > > static void pty_close(struct tty_struct *tty, struct file *filp) > > @@ -674,6 +675,23 @@ static void pty_unix98_shutdown(struct > > tty_struct *tty) devpts_kill_index(tty->driver_data, tty->index); > > } > > > > +static int pty_unix98_break_ctl(struct tty_struct *tty, int > > break_state) +{ > > + int c; > > + struct tty_struct *to = tty->link; > > + > > + if (break_state) { > > + /* Stuff the break data into the input queue of > > the other end */ > > + c = tty_insert_flip_char(to->port, BREAK_STRING, > > TTY_BREAK); > > + /* And shovel */ > > + if (c) > > + tty_flip_buffer_push(to->port); > > + else > > + return -ENOMEM; > > + } > > + return 0; > > +} > > + > > static const struct tty_operations ptm_unix98_ops = { > > .lookup = ptm_unix98_lookup, > > .install = pty_unix98_install, > > @@ -686,6 +704,7 @@ static const struct tty_operations > > ptm_unix98_ops = { .chars_in_buffer = pty_chars_in_buffer, > > .unthrottle = pty_unthrottle, > > .ioctl = pty_unix98_ioctl, > > + .break_ctl = pty_unix98_break_ctl, > > .resize = pty_resize, > > .shutdown = pty_unix98_shutdown, > > .cleanup = pty_cleanup > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/