From owner-freebsd-commit  Tue Oct 31 12:24:42 1995
Return-Path: owner-commit
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id MAA21478
          for freebsd-commit-outgoing; Tue, 31 Oct 1995 12:24:42 -0800
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id MAA21457
          for cvs-all-outgoing; Tue, 31 Oct 1995 12:24:38 -0800
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id MAA21447
          for cvs-sys-outgoing; Tue, 31 Oct 1995 12:24:36 -0800
Received: from Root.COM (implode.Root.COM [198.145.90.17])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA21412
          ; Tue, 31 Oct 1995 12:24:24 -0800
Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id MAA02878; Tue, 31 Oct 1995 12:24:23 -0800
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id MAA09861; Tue, 31 Oct 1995 12:19:16 -0800
Message-Id: <199510312019.MAA09861@corbin.Root.COM>
To: Peter Wemm <peter@freefall.freebsd.org>
cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org
Subject: Re: cvs commit: src/sys/kern tty_subr.c 
In-reply-to: Your message of "Tue, 31 Oct 95 11:00:06 PST."
             <199510311900.LAA17702@freefall.freebsd.org> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Tue, 31 Oct 1995 12:19:16 -0800
Sender: owner-commit@FreeBSD.org
Precedence: bulk

>hsu         95/10/31 11:00:05
>
>  Modified:    sys/kern  tty_subr.c
>  Log:
>  Make a putc()/b_to_q() to a clist that hasn't had cblocks reserved
>  non-fatal.  I've make it return an appropriate error to the caller instead
>  of panic()ing.
>  
>  Handling an error condition is inherently more friendly than exploding
>  the kernel.. :-)  The new behavior is a little closer to traditional
>  clists, potentially making porting a little simpler.
>  
>  Suggested by: bde (many months ago, I've been using this for a while..)

   I just looked at these changes and it appears that you preserve the data
being putc()'d/b_to_q()'d rather than dropping it on the floor. It probably
would be better to toss it out, otherwise you might cause an infinite loop
trying to write it. I don't think the situation will change for the better,
so not tossing out with b_to_q() seems to only result in the data staying in
the uio struct [see the callers of b_to_q()] (for example) which would result
in the process doing the writing to loop trying to do the output.
   I'm tired, however, and may have analyzed this incorrectly.

-DG