From: Peter Hurley <peter@hurleysoftware.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: 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: Wed, 10 Sep 2014 20:11:14 -0400 [thread overview]
Message-ID: <5410E8A2.5030802@hurleysoftware.com> (raw)
In-Reply-To: <20140911000343.GA5328@kroah.com>
On 09/10/2014 08:03 PM, Greg Kroah-Hartman wrote:
> On Wed, Sep 10, 2014 at 05:28:19PM -0400, Peter Hurley wrote:
>> This patch changes user-space behavior (for the better) but I'm not sure
>> that it's consequence-free. Also, it might not be enough to unwedge the
>> terminal if the driver got its own flow control state mangled.
>>
>> Thoughts?
>>
>> --- >% ---
>> Subject: [RFC] tty: Always allow tcflow(TCOON) to unwedge terminal
>>
>> If terminal flow has been stopped, the terminal can be unwedged
>> by:
>> tcflow(fd, TCOOFF);
>> tcflow(fd, TCOON);
>> This works because tcflow(TCOOFF) ensures that ->flow_stopped is set,
>> which allows tcflow(TCOON) to override the terminal flow state in
>> __start_tty().
>>
>> Instead, allow unwedging with only:
>> tcflow(fd, TCOON);
>> by disregarding the existing ->flow_stopped state.
>
> I don't see the benifit here, what are you trying to solve? Sending one
> extra tcflow command?
It's not common knowledge (and its certainly counterintuitive) that
turning off output when output is already turned off (ie., tcflow(TCOOFF))
is the required trickery to unwedge a terminal.
Unwedging directly seems the straightforward approach.
Regards,
Peter Hurley
next prev parent reply other threads:[~2014-09-11 0:11 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 [this message]
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
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=5410E8A2.5030802@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 \
/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.