From: Peter Hurley <peter@hurleysoftware.com>
To: Theodore Ts'o <tytso@mit.edu>,
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 11:40:20 -0400 [thread overview]
Message-ID: <5411C264.8000105@hurleysoftware.com> (raw)
In-Reply-To: <20140911135610.GD15632@thunk.org>
On 09/11/2014 09:56 AM, Theodore Ts'o wrote:
> 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 unwedging software flow control.
Like you point out, unwedging hardware flow control would be more complicated
and less predictable.
> 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).
This is the basic interpretation I assumed, and most of what the tty core
already did.
Regards,
Peter Hurley
next prev parent reply other threads:[~2014-09-11 15:40 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
2014-09-11 15:40 ` Peter Hurley [this message]
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=5411C264.8000105@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--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=tytso@mit.edu \
/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.