On Thu, Mar 07, 2002 at 02:43:36PM -0700, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> 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

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to