Hardware flow control for TTY ports under V.3

[Chris Lewis]

In article <1991Apr14.202750.22010 at mtxinu.COM> ed at mtxinu.COM (Ed Gould) writes:
>>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.

There were a number of serial I/O systems back in "those" days that
could support rudimentary hardware flow control enabling/disabling.
I believe, for example, that several of the VAX serial port controllers
had the capability - and were as programmable as some of the newest
intelligent port cards.

On the other hand, when I installed V6 on a PDP 11/23 (a 11/23 was
pretty darn modern compared to V6), I had to use a wire-wrap gun to
change the baud rate - stty() couldn't do it.  (a "dj" if I recall
correctly)

I think the real reason was that nobody thought hardware flow control
was all that important.  After all, they didn't have 9600 baud modems
then.  In retrospect, something should have been specified even if it
wouldn't work in many systems.  After all, V7 had "phys()" (map physical
memory), and TANDEM - neither of which worked on a significant portion
of the machines it ran on.  If something had been specified, we'd have
a lot easier time now without having all of these mutually exclusive
mechanisms that are done by vendor-specific kludges.
-- 
Chris Lewis, Phone: (613) 832-0541, Internet: clewis at ferret.ocunix.on.ca
UUCP: uunet!mitel!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request at eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request at eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!