From owner-freebsd-hackers Fri Jun 27 05:37:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA19627 for hackers-outgoing; Fri, 27 Jun 1997 05:37:05 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA19622 for ; Fri, 27 Jun 1997 05:37:02 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id WAA25388; Fri, 27 Jun 1997 22:32:51 +1000 Date: Fri, 27 Jun 1997 22:32:51 +1000 From: Bruce Evans Message-Id: <199706271232.WAA25388@godzilla.zeta.org.au> To: bde@zeta.org.au, mcgovern@spoon.beta.com Subject: Re: XON/XOFF intrusion Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >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 This is so that ttyblock() gets called to handle all types of flow control. Bruce