From: utzoo!decvax!microsof!uw-beaver!cornell!vax135!ariel!hou5f!hou5b!hou5c!hou5e!hou5a!jhc
Newsgroups: net.unix-wizards
Title: hardware flow control on UNIX - a plea
Article-I.D.: hou5a.333
Posted: Thu Apr 21 22:11:01 1983
Received: Sun Apr 24 06:40:56 1983


I have an Ungermann-Bass Ethernet installation which allows
three methods of programming flow control - ^S/^Q, toggling
CTS (and responding to RTS), and toggling DSR(and responding
to DTR).

This is great, except that my DZ's don't understand CTS and so
I have to use ^S/^Q, which screws up EMACS when the NIU
flow-controls the VAX (which happens ALL the time).

I thought I would try to put something into the tty driver
that would understand hardware flow control, and supply
same if necessary. I have no particular hardware in mind,
(actually I have a full set of leads available on the
board I am thinking of, but anyway).

My question is has anyone else done this, or thought about it,
or even implemented it. I am familiar with the Berkeley
'tandem' concept and it seems OK, but it only does ^S/^Q.

My current thoughts lean towards putting some extra bits
into the c_lflag field or tty(4)/termio(7), and doing
user-level flow control via the TCXONC ioctl call (that
should be 'of' earlier, not 'or').

The c_lflag field would determine the type of flow control
(CTS/RTS (my favourite), DSR/DTR, or ^S/^Q), and the ioctl
call would tell the driver when to turn it on or off. ^S 
and ^Q would be passed through undisturbed in all cases.

Any comments, flames, ideas or questions please let me know.
All replies acknowledged (not for ARPA - I can't get through).

I will summarize to the net iff there are 'sufficient' responses.

				Jonathan Clark
				ABI Holmdel
				[houx*|ariel]!hou5a!jhc