All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.cz>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] tty: Always allow tcflow(TCOON) to unwedge terminal
Date: Thu, 11 Sep 2014 09:56:10 -0400	[thread overview]
Message-ID: <20140911135610.GD15632@thunk.org> (raw)
In-Reply-To: <5410F08D.10707@hurleysoftware.com>

On Wed, Sep 10, 2014 at 08:45:01PM -0400, Peter Hurley wrote:
> > I'm all for working around broken hardware in the kernel, but this seems
> > like a very old issue, if it's even one at all, that we would be
> > changing for no one who has reported it (that I know of...)
> 
> How to unwedge a terminal comes up from time to time.

Are you trying to unwedge a terminal using hardware flow control, or
software flow control?

For software flow control, this is a guarantee that we can make wrt to
the behavior of tcflow().  For hardware flow control, we can't make
any guarantees, whether it's with tcflow(TCOON) or tcflow(TCOOF);
tcflow(TCOON). 

> It's possible that this may cause userspace breakage. Some app
> may call tcflow(TCOON) thus accidently overriding the flow control
> state when it would have had no effect before.

It's very likely that an application that would be using tcflow() at
all would first be sending a TCOOFF, and then sending a TCOON.  So
this doesn't worry me that much.

Indeed, given that the definition of how TCION and TCIOFF is worded
(send a START or STOP command), it's completely reasonable to
interpret TCOON and TCOOFF as emulating what would happen if the
system received a START or STOP command.  (Note though that part of
this is that Posix doesn't define CRTSCTS, so POSIX is entirely silent
on the subject of hardware flow control).

Cheers,

					- Ted

  reply	other threads:[~2014-09-11 13:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-10 21:28 [RFC] tty: Always allow tcflow(TCOON) to unwedge terminal Peter Hurley
2014-09-11  0:03 ` Greg Kroah-Hartman
2014-09-11  0:11   ` Peter Hurley
2014-09-11  0:24     ` Greg Kroah-Hartman
2014-09-11  0:45       ` Peter Hurley
2014-09-11 13:56         ` Theodore Ts'o [this message]
2014-09-11 15:40           ` Peter Hurley
2014-09-11 15:50             ` Theodore Ts'o
2014-09-11 10:19     ` One Thousand Gnomes
2014-09-11 12:34       ` Peter Hurley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140911135610.GD15632@thunk.org \
    --to=tytso@mit.edu \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=peter@hurleysoftware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.