From owner-cvs-all Tue Feb 26 14:43:36 2002 Delivered-To: cvs-all@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5C34337B402; Tue, 26 Feb 2002 14:43:24 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1QMgro98338; Tue, 26 Feb 2002 14:42:53 -0800 (PST) (envelope-from dillon) Date: Tue, 26 Feb 2002 14:42:53 -0800 (PST) From: Matthew Dillon Message-Id: <200202262242.g1QMgro98338@apollo.backplane.com> To: Julian Elischer Cc: Warner Losh , Robert Watson , Garance A Drosihn , Alfred Perlstein , Jake Burkholder , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/i386 exception.s genassym.c machdep.c mp_machdep.c mpapic.c swtch.s vm_machdep.c src/sys/i386/include cpufunc.h pcb.h src/sys/i386/isa apic_vector.s clock.c icu_vector.s intr_machdep.c intr_machdep.h npx.c src/sys/kern ... References: Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I would characterize it more as "Extenuating the problem rather then helping solve it". The basic question here is: Do I have a right to commit this code? I've offered to work with anyone who has a problem with the code, or with merging their own code. I have instrumented it so people can turn it on or off for testing purposes. It solves problems that nobody else but BDE has solved (and I used his patch set as a basis for some of the work with his permission). All of the other issues are ephermal, like John's "I have X month old stale preemption code that will not be committable for a while, you should wait". I don't see what the big deal is, it's not as though I would be unwilling to discuss merge issues for the preemption code! It is not as though I am making a huge change to the API. I don't like the idea of preemption, true, but that does not mean I would try to actively prevent it from going in or actively code to make it difficult!. Why does all of this crap have to occur before my commit? It is a whole lot more efficient for it to occur afterwords. So why am I being prevented from committing this? As I've said, I am the kind of person who is always willing to evolve committed code when it does not perfectly fit with new work. The VM system would not be half as good as it is today if we had tried to set things in stone after the commit, let alone setting it in stone BEFORE a commit! This whole business about getting the SMP algorithms 'just right' before doing anything is just plain dumb. -Matt Matthew Dillon :No 1 week is unrealistic. : :On Tue, 26 Feb 2002, Warner Losh wrote: : :> In message Julian Elischer writes: :> : This decision must be forthcoming within about 48 hours or core is falling :> : down on the job. :> :> Core generally has a 1 week timeout for its discussions. We'll do :> what we can, but 48 hours is an unrealistic expectation. :> :> Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message