Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!ames!zorch!hico2!sonyd1.Broadcast.Sony.COM!blilly.UUCP!bruce
From: bruce@uucp (Bruce Lilly)
Newsgroups: comp.sys.3b1
Subject: Re: hardware flow control
Message-ID: <1991Mar20.033336.23302@blilly.UUCP>
Date: 20 Mar 91 03:33:36 GMT
References: <1991Mar19.045702.2004@nntp-server.caltech.edu>
Sender: usenet@blilly.UUCP (News Administrator)
Organization: Bruce Lilly, Flushing, NY
Lines: 52
Nntp-Posting-Host: balilly

In article <1991Mar19.045702.2004@nntp-server.caltech.edu> andy@cs.caltech.edu (Andy Fyfe) writes:
>
>...  Is hardware flow control simply turned on
>and off with the CTSCD bit in the termio control flags?  Does one need
>to use the mystic program in /etc?  What does the program actually do?

No, no, and according to the output of running strings on /etc/hfc_ctl, it
does an undocumented ioctl.

CTSCD only works if HFC is already on.

/etc/hfc_ctl can be used, but one could also call the ioctl.

strings /etc/hfc_ctl:
::::::::::::::
/etc/hfc_ctl
::::::::::::::
%s: error %d opening %s
Usage: %s [+|-]ttyport
%s: error %d on TCHFCCTL ioctl
@(#) adminbin:adminbin.sl 1.137 

TCHFCCTL isn't in any of the header files (at least not the ones which
came with the base 3.51 or development set), but it would appear to be
something like:

#define	TCHFCCTL	(TIOC | 15)

in the style of termio.h.

An arg of 0/1 turns HFC off/on.

There appears to be a kernel variable "hfc_dev", which seems to be a type
of bit mask for tty's with HFC turned on, but the mapping isn't entirely
lucid (and it doesn't do one any good unless one's program is run as a
user or group which can read /dev/kmem). There's also an "hfc_csq", but
I've no idea what that does.

Note that unlike SVR4, one cannot have both HFC and XON/XOFF (soft) flow
control. If HFC is on, XON/XOFF is disabled, and there's no easy way to
determine whether or not HFC is on or off (see above).

(Regarding the plan to get source for the 3b1, if we're going to do it,
let's do it right and get the latest, so that some problems (like the
above) can be cleared up -- and having some BSD compatibility a la SVR
wouldn't hurt either (the 4.2BSD networking stuff from Wollongong is
buggier than a boatload of bananas).)
>
>Andy Fyfe					andy@cs.caltech.edu

--
	Bruce Lilly		blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM