Subject: Re: Please Revert newlock2
To: None <tech-kern@netbsd.org>
From: Bucky Katz <bucky@picovex.com>
List: tech-kern
Date: 02/21/2007 13:52:17
"Greg A. Woods" <woods@planix.com> writes:

> But that just shows that you really do not yet "get it" with respect
> to the use of -current by a third party developer such as yourself.

Um, no it doesn't. But we've been over that ground a lot in this
thread, so I won't go over it again.


> You should not have been relying on -current in the first place,
> thus in reality nobody has so far removed anything you should be
> depending on.

We were in -current because a) OMAP didn't make it into 4.0 --
something that has since been rectified and b) we had code we wanted
to give back -- something we've given up on, for the moment.

We were there fully aware of the nature of how -current _should_ be
used in an OS development environment.

> If your argument were originally stated as something like this:
>
> 	"Can someone please make sure that SA will work with newlock2 so
> 	as to provide efficient M:N threading via libpthread on
> 	uniprocessor systems before the newlock2 code reaches a release
> 	branch?"

Yes. In a perfect world I would have been able to read Andrew Doran's
mind and know that he was going to blow up M:N for uniprocessor -
something he didn't know himself until a few weeks before he did it,
and something he didn't communicate to me after I'd sent him email
with a patch to review.  This _is_ old ground now.

The inability of users to read the mind of developers is why in the
_real_ world, it is traditional for developers to announce intent to
break existing functionality and _solicit_ that sort of input from
users.  Core has admitted that should have been done here.  Can we
move on now?

> Since you're talking about the bleeding edge of -current I think the
> following sound quote and its derivations over time, especially the
> last one, apply:
>
> Premature optimization is the root of all evil in programming.
> 	-- C.A.R. Hoare

When the purpose of your project is optimization, Hoare's aphorism
hardly applies.  Neither to do the two I cut out.

One _purpose_ of newlock2 *is* optimization. Measuring whether it in
fact optimizes should be de rigour.  How will you know if it met its
purpose otherwise?