Subject: Re: what was wrong with m:n, was Re: newlock2 breaks arm
To: None <tech-kern@netbsd.org>
From: Bucky Katz <bucky@picovex.com>
List: tech-kern
Date: 02/18/2007 00:01:53
Bill Studenmund <wrstuden@netbsd.org> writes:

> On Sat, Feb 17, 2007 at 09:55:12PM -0800, Bucky Katz wrote:
>> 
>> Let me rephrase the question: If the only thing that changes was
>> the implementation of primitives, why does m:n have to come out? On
>> the other hand, if more changed, why do you think that just
>> implementing the primitives is enough to fix an arch?
>
> I think that implementing the primitives will fix an arch for
> compilation, thus the (implied) use of "just".
>

Sorry, it's late in this timezone and I'm still confused but as I
understand it you're saying that implementing the primitives will
cause the arch to start compiling again, but that other changes are
needed for 'compiles' to turn into 'works'?


> Well, the point of new-lock is to make the kernel away from big-lock. So 
> the threading code needing big-lock will not do.

Changing the primitives doesn't get you that. You have to do a lot of
surgery on subsystems to fix locking.  In fact, the _last_ thing I'd
do as part of trying to make my locking more fine grained is to start
by doing new locking primitives.

> I wish we'd known that you might be in a position to help fix
> SA. Things would probably been handled differently.

As I understand it, things are still being handled poorly. I've heard
through the rumor mill that private technical discussions about how to
fix locking in ARM are being held and no one is bothering to include
us. (This is not unexpected. I would have been _very_ surprised if the
problem of having technical discussions with the wrong audience could
be fixed that quickly. And, of course, the rumor mill could be wrong.)

> As to the long-term options for SA, I'd love it if someone would fix
> it.  The system calls are still assigned, and the calls can be
> re-added once there's a good implementation. I'm not 100% sure how
> we'd live w/ two libpthreads, but I'm sure we can figure it out.

Personally, I'd burn down SA. There are better ways to get to M:N
threading.

> So if you can get SA working, please do!

At this point, I don't even have time to fix the problems that
dropping m:n is causing us.