Date: Fri, 8 Mar 2002 10:58:03 +1030 From: Greg Lehey <grog@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Warner Losh <imp@harmony.village.org>, Julian Elischer <julian@elischer.org>, "Justin T. Gibbs" <gibbs@scsiguy.com>, John Baldwin <jhb@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, FreeBSD current users <current@FreeBSD.ORG> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <20020308105803.R66287@wantadilla.lemis.com> In-Reply-To: <200203072230.g27MUl170046@apollo.backplane.com> References: <Pine.BSF.4.21.0203071334010.37321-100000@InterJet.elischer.org> <200203072143.g27LhaL97112@harmony.village.org> <200203072230.g27MUl170046@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, 7 March 2002 at 14:30:47 -0800, Matthew Dillon wrote: > >>> after reverting the change and silently waiting for a week >>> 1/ no person bothered to review it. >>> 2/ people assumed the patch had gone away. >> >> Ummm, There are reviews in the archives that object to the API as it >> relates to optimization and those objections haven't been sanely >> answered with anything more constructive than "BS". >> >> Warner > > I think John has a right to object to the work based on it being an > optimization, but that should not sufficient reason in anyone's book to > veto a commit, especially something that is as straightforward and > obvious as I believe my work to be in this case. I think this is a good point. We're in a development phase now, and we shouldn't step on each others' feet. But Matt has gone to some trouble to ensure it can be turned off at will. Come a release, it's possible that the project manager might decide to chop it out again, but I'm betting on it staying. Another issue: sure, it's partially an optimization. Sure, it contains MD code. But it also fixes bugs. Should a policy of "structure now, optimize later" mean we should reject bug fixes which also perform better? And will we, in the long term, be able to eliminate MD code and still have good performance? I think the issue of "i386 only" is a non-issue. It has to start somewhere, and it doesn't break the other platforms. > Unlike John, I am not the type of person who leaves hundreds of > kilobytes of patches laying around my tree. For me completed > work is either committable, or it should be thrown away. Without prejudice to John (I don't know how much uncommitted stuff he has), I think that Matt's right here too. Where practicable, smaller increments are easier to handle. > John's other objections - in regards to interference with future work, > are completely unsubstantiated. He has not explained any reasoning for > his objections AT ALL other then to make vague, undirected comments > about how it doesn't fit with his idea of the world. He pointed me to > a 10-page mini paper and I even after reading it I do not see how any > of my work inteferes with anything he is doing. Core has asked John to describe his objections. Based on the current flam^H^H^H^Hdiscussion, I'm sure people will agree that it's probably better to discuss things in a smaller group first. The results will, of course, be made known. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020308105803.R66287>