From owner-freebsd-arch  Wed Feb 20 17:10:52 2002
Delivered-To: freebsd-arch@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1F2A637B400; Wed, 20 Feb 2002 17:10:49 -0800 (PST)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.11.6/8.9.1) id g1L1Amw91277;
	Wed, 20 Feb 2002 17:10:48 -0800 (PST)
	(envelope-from dillon)
Date: Wed, 20 Feb 2002 17:10:48 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200202210110.g1L1Amw91277@apollo.backplane.com>
To: John Baldwin <jhb@FreeBSD.org>
Cc: Peter Wemm <peter@wemm.org>, arch@FreeBSD.org,
	Robert Watson <rwatson@FreeBSD.org>, Alfred Perlstein <bright@mu.org>
Subject: Re: John Balwdin's proc-locking patch
References:  <XFMail.020220172730.jhb@FreeBSD.org>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

:>> > 
:>> >     That is my position.
:>> 
:>> I've felt the same way for a while.
:> 
:> Nobody is disputing that.  It would have been better if John had committed
:> it piecemeal, but it didn't work out that way.  I doubt he'll fall for this
:> trap again.
:
:Actually, I tried to do it piecemeal and ended up with a kernel that wouldn't
:boot. :(
:
:-- 
:
:John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
:"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

    Well... try again.  If something ought to be compatible in a piecemeal
    commit and isn't, then something unexpected happened and you need to
    find out what it was.  Doing a full-on commit for something like the
    proc lock patch is far too dangerous.  It's just too large a patch set
    and we know from experience (cam, softupdates, etc...) that having a
    small handful of people testing a large private patch is not going to
    find all the bugs.  This is why I introduced the mtx_lock_giant() 
    family of calls in the first place .. to allow pushdown work to
    be committed piecemeal without turning Giant off, so developers working
    on unrelated subsystems don't get unexpected timing changes or crashes
    if, for example, you forget to PROC_LOCK a particular piece of code.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message