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 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
