hardware/software flow control on tty ports

[Bruce Lilly]

There is apparently some undocumented interaction between hardware
and software flow control on the 3B1. First some background:

The tty driver permits software flow control for the input queue, so
that when the input queue is ``nearly'' (undocumented) full, a CSTOP
(control S) will be output, and when the queue is nearly empty a
CSTART (control Q) is sent.  This is controlled (supposed to be) by
the IXOFF bit in the c_iflag int in the termio structure.  Refer to
the termio(7) man page for more details.

The 3B1, at least in 3.51 and later OS versions, also has a program,
/etc/hfc_ctl, which can turn hardware (RTS/CTS) flow control on or off
for a port.

The problem:

What is not mentioned in the manual pages is that if hardware flow
control is turned on for a port, software flow control doesn't work --
the IXOFF bit is effectively ignored.  There also doesn't appear to be
any (documented) way to determine whether hardware flow control has
been turned on, or is off, for any given port.  The return value (exit
status) from /etc/hfc_ctl certainly isn't of any use in this regard.

This means that if a program needs software flow control (e.g. a
communications program which needs to suspend output from a remote
computer), one ought to run /etc/hfc_ctl to turn off flow control for
the port being used (in case it had been turned on).  Because there's
no way to know whether flow control was on or off, there's no way to
restore the previous state.  Therefore, any program which needs
hardware flow control, also should run /etc/hfc_ctl to turn it on.

Arghh...

If anybody knows of a way for a program to determine the state of
hardware flow control, I'd like to hear about it.

Note: running strings on /etc/hfc_ctl reveals that it apparently uses
a TCHFCCTL (undocumented) ioctl.
-- 
	Bruce Lilly		blilly!bruce at Broadcast.Sony.COM
					...uunet!sonyusa!sonyd1!blilly!bruce