Date: Tue, 26 Feb 2002 14:42:53 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@elischer.org> Cc: Warner Losh <imp@harmony.village.org>, Robert Watson <rwatson@FreeBSD.ORG>, Garance A Drosihn <drosih@rpi.edu>, Alfred Perlstein <bright@mu.org>, Jake Burkholder <jake@locore.ca>, 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 ... Message-ID: <200202262242.g1QMgro98338@apollo.backplane.com> References: <Pine.BSF.4.21.0202261345300.94891-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
<dillon@backplane.com>
:No 1 week is unrealistic.
:
:On Tue, 26 Feb 2002, Warner Losh wrote:
:
:> In message <Pine.BSF.4.21.0202261248580.94891-100000@InterJet.elischer.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202262242.g1QMgro98338>