Date: Thu, 7 Mar 2002 18:24:46 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Warner Losh <imp@harmony.village.org> Cc: Julian Elischer <julian@elischer.org>, "Justin T. Gibbs" <gibbs@scsiguy.com>, Matthew Dillon <dillon@apollo.backplane.com>, John Baldwin <jhb@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, 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: <20020307182446.A92444@unixdaemons.com> In-Reply-To: <200203072143.g27LhaL97112@harmony.village.org>; from imp@harmony.village.org on Thu, Mar 07, 2002 at 02:43:36PM -0700 References: <Pine.BSF.4.21.0203071334010.37321-100000@InterJet.elischer.org> <200203072143.g27LhaL97112@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 07, 2002 at 02:43:36PM -0700, Warner Losh wrote: > In message <Pine.BSF.4.21.0203071334010.37321-100000@InterJet.elischer.org> Julian Elischer writes: > : > : > : On Thu, 7 Mar 2002, Justin T. Gibbs wrote: > : > > : > Then do the right things so it will. > : > : Unfortunatly that has been proven to not work. > : > : 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". They are BS. Saying "it's not good because it's an optimization" is not a technical argument. I've already mentionned this before but I'm going to do it one more time, for the record: "optimizations" can be anything in SMPng. Heck, you could say that locking down a subsystem is an "optimization." Even doing lockdowns (what John wants everyone to be doing) is something that is likely to change in the future. You can't prevent API changes from happening, they are part of regular evolutionary steps. Just look at what happened to the mbuf subsystem. I initially locked it down and it has changed an incredible amount. The API changed, other things changed. It's normal because it's part of regular code evolution. Therefore, you can't just say that the work some of us are doing is an "optimization" and that because it is that we shouldn't be doing it right now. These are things that have been in the TODO for a while now and are part of the general direction of this project and delaying them by claiming that "it's too early and that the API might change" is just preventing them from getting tested. Sure, the API may change. That's normal. You can't possibly get the API right at step 1. But you _can_ get the backend stuff at least working in the right direction. The same thing happened to our mutex code. The API totally changed (I cleaned it up myself). But does that mean that all the initial work done on mutex locks was wrong? I hope not. Without it, we never could have evolved to where we have. I've looked at both JHB's paper and Matt's patch. To me, it doesn't look like the direction we're supposed to be headed in is wrong. I don't see a technical argument (yet) saying otherwise besides for this "it's an optimization and shouldn't go in" thing. Please, if there is one, state it. The same applies to the ithread lightweight stuff I've been working on. > Warner -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org 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?20020307182446.A92444>