From owner-cvs-sys  Tue Aug  8 15:42:04 1995
Return-Path: cvs-sys-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id PAA19024
          for cvs-sys-outgoing; Tue, 8 Aug 1995 15:42:04 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id PAA19016
          ; Tue, 8 Aug 1995 15:41:56 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id PAA05313; Tue, 8 Aug 1995 15:41:34 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199508082241.PAA05313@gndrsh.aac.dev.com>
Subject: Re: cvs commit: src/sys/i386/isa syscons.c
To: davidg@Root.COM
Date: Tue, 8 Aug 1995 15:41:33 -0700 (PDT)
Cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com
In-Reply-To: <199508082129.OAA02174@corbin.Root.COM> from "David Greenman" at Aug 8, 95 02:29:13 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1452      
Sender: cvs-sys-owner@freebsd.org
Precedence: bulk

> 
> >> 
> >> > Actually it isn't really OK to simply substitute M_NOWAIT with M_WAITOK.
> >> > If one of the malloc()s in scioctl() sleeps, then another process may
> >> > run and use the half-allocated resources.  If one of the malloc()s in in
> >> > scioctl() or scopen() sleeps, then another process may run and repeat the
> >> > ioctl and (at best) allocate the resources twice.
> >> 
> >> Argh.  Perhaps I was too hasty.  If John decides to rearchitect this,
> >> I'll pull it out of 2.1
> >
> >We really should let bits sit in -current for a week or two before pulling
> >them into the 2.1 branch, per David's mail on this subject about how to get
> >stuff into the branch, I though that was the plan.  This allows time for
> >these types of problems to surface so we don't have to go back things out
> >of the -stable branch.
> 
>    I've generally been doing this, with a few exceptions for extremely well
> understood changes...but even those usually get a few days of testing in
> -current.
>    Generally, assume that I'm responsible for managing what contributions make
> it into the 2.1 branch. I spend a large amount of time evaluating and testing
> things before bringing them in, and short circuiting this procedure only
> results in the reduced quality of the product.

Agreed.


-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD