From owner-cvs-all Tue Feb 26 14:33:16 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 54B2B37B400; Tue, 26 Feb 2002 14:33:07 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1QMX6D98254; Tue, 26 Feb 2002 14:33:06 -0800 (PST) (envelope-from dillon) Date: Tue, 26 Feb 2002 14:33:06 -0800 (PST) From: Matthew Dillon Message-Id: <200202262233.g1QMX6D98254@apollo.backplane.com> To: Robert Watson Cc: Garance A Drosihn , Alfred Perlstein , Julian Elischer , 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 :Perhaps I'm not recalling an earlier incident. The number of times where :I've asked you not to commit something because something identical exists :in a jhb tree is precisely 1. That's not a very big N. One hates to dig :up long dead issues, but could you expound on what you are referring to? Two that I would put in the aggregious category (UCRED, critical*), one that was really quite annoying (the ucred NULLing code) and ate half a week of both Julian and my time, the pool mutex expansion argument which I would label as 'annoying', not to mention a few others. And then there is the constant spew of 'Matt doesn't know what he is talking about' crap on IRC, which is really getting on my nerves. I was doing SMP on 8 bit cpu's 18 years ago for gods sake! And constant references to 'the plan' for this or that, which is in John's head apparently, and totally undocumented source code, or constant references to how 'other people do it' -- a fine discussion point, but no excuse to not do something a different way and certainly no justification to object to another viewpoint. Hello! FreeBSD is NOT solaris. Well, I've had it. I am not coddleing up to this crap any more. If there were no interference I would be *done* with stage-2 by now, instead of still waiting to get stage-1 in place. I would have had UCRED completely instrumented by now, instead of still waiting for a tiny patch to read-only functions in a single file to get unstalled (or even for JHB to commit some of his stuff, in which case I would like to be able to instrument Giant). And I'll tell you something else, too. I'm not afraid to make changes if I turn out to be wrong on something. I'm not afraid to rip out and redo code. It's how I work best, in fact, and should not be confused to 'working' vs 'non-working' code. Theory works only up to a point, then you actually have to code it up and have a lot of people play with it. Nobody who tries to engineer an entire system all in one go will succeed, or certainly not succeed in any worthwhile time frame. John is welcome to work that way but he should not drag the rest of us (and specifically me) down with him. Even the 4 hours that this commit was in the tree reaped benefits. I've already had several people email me that it works, and Ian even found a minor bug that can occur if a process switches tasks while in a critical section. To me that is a huge reward, because I specifically instrumented the code with a sysctl to turn it off so when Ian reported that to me it took two seconds for him to verify that it was the new critical code and another few seconds for me to locate and solve the problem. Try that with a mega-commit and see how far you get! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message