Hardware flow control for TTY ports under V.3

[Ed Gould]

>There is no portable way to do hardware handshake under UNIX. The
>termio(7) man page author didn't think of it (this is the only
>explanation I have for that omission).

There is exactly one reason that the termio(7) page doesn't describe
portable hardware flow control.  That reason is that it doesn't
exist.  The man pages document *existing* systems.  They are not
specifications for something that doesn't exist.

There is also a reason why the termio software doesn't specify or
support hardware flow control.  When that software was being
developed, there was a wide variety of types of serial ports
available.  Some had provisions, for RTS/CTS flow control, but they
were by far the exception, not the rule.  Many ports had no
modem-control support at all, some had only carrier detect, and
some had full support for the signals.  However, what "full support
for the signals" meant was that the *software* could look at them.

This is all consistent with the long-since-adopted EIA RS232C
standard (note - industry standard, not one person's idea of how
it should work).  RS232C (while it may be outdated) does not have
the notion of flow control, per se.  It knows about line turnaround
for half-duplex systems.  That is what RTS (request to send, sent
from the DTE - in this case the computer - to the modem) and CTS
(clear to send, from the DCE - modem - to the computer) were designed
for.  Hardware flow control came along and coopted those signals
for other purposes.

There still exist half-duplex systems in the world.  Would you
suggest that hardware manufacturers abandon the standard that
supports them in favor of an ad-hoc solution that works in some
situations?  That's not what I think standards are for.

-- 
Ed Gould			No longer formally affiliated with,
ed at mtxinu.COM			and certainly not speaking for, mt Xinu.

"I'll fight them as a woman, not a lady.  I'll fight them as an engineer."