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
next prev parent 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.