From owner-freebsd-current Thu Mar 7 15:25:16 2002 Delivered-To: freebsd-current@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id 7462D37B416; Thu, 7 Mar 2002 15:25:05 -0800 (PST) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.2/8.12.1) with ESMTP id g27NOkAX009823; Thu, 7 Mar 2002 18:24:46 -0500 (EST) Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.2/8.12.1/Submit) id g27NOkAa009813; Thu, 7 Mar 2002 18:24:46 -0500 (EST) (envelope-from bmilekic) Date: Thu, 7 Mar 2002 18:24:46 -0500 From: Bosko Milekic To: Warner Losh Cc: Julian Elischer , "Justin T. Gibbs" , Matthew Dillon , John Baldwin , Bruce Evans , Terry Lambert , Alfred Perlstein , Seigo Tanimura , FreeBSD current users Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <20020307182446.A92444@unixdaemons.com> References: <200203072143.g27LhaL97112@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200203072143.g27LhaL97112@harmony.village.org>; from imp@harmony.village.org on Thu, Mar 07, 2002 at 02:43:36PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 07, 2002 at 02:43:36PM -0700, Warner Losh wrote: > In message 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