From owner-freebsd-hackers  Fri Jun 27 05:06:18 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id FAA18286
          for hackers-outgoing; Fri, 27 Jun 1997 05:06:18 -0700 (PDT)
Received: from spoon.beta.com (root@[199.165.180.33])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA18281
          for <hackers@freebsd.org>; Fri, 27 Jun 1997 05:06:14 -0700 (PDT)
Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1])
	by spoon.beta.com (8.8.5/8.8.5) with ESMTP id IAA16904;
	Fri, 27 Jun 1997 08:06:00 -0400 (EDT)
Message-Id: <199706271206.IAA16904@spoon.beta.com>
To: bde@zeta.org.au
cc: hackers@freebsd.org
Subject: Re: XON/XOFF intrusion
Date: Fri, 27 Jun 1997 08:06:00 -0400
From: "Brian J. McGovern" <mcgovern@spoon.beta.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>>I'm having a problem with a driver where XON and XOFFs are being introduced
>>to the data stream, even when I have IXON, IXOFF, and IXANY turned off
>>in c_iflag.
>
>This shouldn't happen.  Spurious XONs and XOFFs are only introduced into
>the output data stream when the line discipline is the default (termios)
>and IXOFF is set, at least by the machine-independent part of the driver.
>IXON and IXANY have no effect on the output data stream.
>

I agree completely. But take a look below...

>>I know (through programming and printf()s) that c_iflag has the above
>>mentioned bits off, and that ((tp->t_rawq + tp->t_canq) < (TTYHOG / 2)).
>
>Perhaps IXOFF is actually set and tp->t_rawq + tp->t_canq grows soon after
>you look at it.
>

Nope. I have IX* printfs right in the interrupt handler. If it gets turned
on, it'd have to get turned right back off again. The one routine that does
do the setting of flow control has the values &= ~(...)'ed right before
the hardware is set. Chances of it floating on elsewhere - slim to none (tho
I won't say its 0)

>I_HIGH_WATER is too small for some devices.  Flow control won't work if
>the device ever buffers more than about 512 bytes of input.  TTYHOG is
>too small for some devices.  Flow control can't work if the device ever
>buffers more than about TTYHOG (= 1024) bytes of input.  Drivers should
>read from the device often enough to reduce the burst length to <= 256.
>At 115200 bps, this means that they must read from the device at least
>once every 22.2 msec.  In practice this means reading every clock tick.
>

Sounds about right. The device I'm playing with has 8K of onboard receive
buffer. I'm using hardware-induced RTS/CTS signaling. The line disc. should
never have to eat more characters than it wants at any given time.

However, I did note one interesting thing in tty.c (/usr/src/sys/kern), 
starting on line 318 (version 2.2.1). Its the if statement that decides
if ttyblock() gets called. I did some reduction of the expression,
and got (in pseudo-code):

if ( (tp clists > 512) && (!ICANON || tp->t_canq.c_cc != 0) && 
	(CRTS_IFLOW || IXOFF) && !TS_BLOCK)

I'd buy most of that as being reasonable, except the CRTS_IFLOW portion. Why
would I want to introduce Xon/Xoff handling if I have CRTS_FLOW? Especially
when this flag represents half of hardware flow control? I think it should
be !CRTS_IFLOW. Or, more appropriately, it should be removed from the 
expression so that hardware and XON/XOFF flow control can be used at the same
time if so desired (tho I can't see a rational as to why you'd really want to
do that).

Am I wrong? Am I missing something? Please, set me right. :)

	-Brian