From owner-freebsd-commit  Tue Aug  8 14:28:59 1995
Return-Path: commit-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id OAA15915
          for commit-outgoing; Tue, 8 Aug 1995 14:28:59 -0700
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id OAA15901
          for cvs-sys-outgoing; Tue, 8 Aug 1995 14:28:54 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.17])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id OAA15893
          ; Tue, 8 Aug 1995 14:28:32 -0700
Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.11/8.6.5) with ESMTP id OAA11073; Tue, 8 Aug 1995 14:27:37 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id OAA02174; Tue, 8 Aug 1995 14:29:14 -0700
Message-Id: <199508082129.OAA02174@corbin.Root.COM>
To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com
Subject: Re: cvs commit: src/sys/i386/isa syscons.c 
In-reply-to: Your message of "Tue, 08 Aug 95 10:26:16 PDT."
             <199508081726.KAA04241@gndrsh.aac.dev.com> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Tue, 08 Aug 1995 14:29:13 -0700
Sender: commit-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.

-DG