From owner-freebsd-hackers Sun Aug 3 08:22:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA28433 for hackers-outgoing; Sun, 3 Aug 1997 08:22:26 -0700 (PDT) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA28428 for ; Sun, 3 Aug 1997 08:22:22 -0700 (PDT) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.5) id LAA07649; Sun, 3 Aug 1997 11:21:47 -0400 (EDT) Message-ID: <19970803112147.21483@crh.cl.msu.edu> Date: Sun, 3 Aug 1997 11:21:47 -0400 From: Charles Henrich To: Michael Smith Cc: tom@sdf.com, freebsd-hackers@FreeBSD.ORG Subject: Re: tty-level buffer overflows References: <19970803025730.57257@crh.cl.msu.edu> <199708030852.SAA13473@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.80 In-Reply-To: <199708030852.SAA13473@genesis.atrad.adelaide.edu.au>; from Michael Smith on Sun, Aug 03, 1997 at 06:22:34PM +0930 X-Operating-System: FreeBSD 2.2.2-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On the subject of Re: tty-level buffer overflows, Michael Smith stated: > > Not in this case, its a 16550A, on a 486/66 doing absolutely nothing > > except trying to do filetransfer over the serial port with a custom app I > > wrote.. > > And of course if you bothered to read the sio(4) manpage it would tell you > what the error message means. Or if you'd mentioned that you're using a Ooh, arent we high and mighty. I did read the man page, one line that says "The application is broken" is about as useless as it gets. As my original message said, I've waded through all the message archives searching for an anaswer, Im not about to waste peoples time without having spent a considerable amount of effort attempting to figure it out on my own. > Your application is busted; data is arriving faster than your app is reading > it, and the kernel has run out of patience and started throwing the data > away. Im afraid not, the application is a software Upload, with a singly byte ack every 2k, if the serial port cant handle that, theres a problem. I would presume that if the buffer is full, a write() should block. -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich