On Feb 14, 2007, at 11:23 PM, Bucky Katz wrote:

>
> Michael Lorenz <macallan@netbsd.org> writes:
>
>> It got removed from -current, AFTER 4.0 was branched so the first
>> release with the new threading code will be 5.0 which will probably
>> happen in 2008 or later. Unless you're using -current in whatever
>> product you're working on you have plenty of time to adjust and
>> whatever fixes you come up with will be useful for the 4.0 branch.
>> I would understand such an outcry if a change like that had  
>> happened on
>> a release branch but - well - it didn't.
>
> Guess who has to work in -current because the arm port maintainer
> didn't commit the OMAP architecture in time for it to make the 4.0
> branch?

You could request the OMAP arm changes be pulled up into 4.0.  4.0 is  
not yet cast into stone.

> The 'outcry' is in response to not one bit of brokenness from the
> NetBSD foundation, but rather in response to a many month sequence of
> brokenness that cumulated in the M:N straw breaking my patience and
> making me sad.
>
> [...]
>
> Even if I have "plenty of time to adjust", that's missing the
> point. Those of us developing for NetBSD should be consulted before
> major pieces of functionality are removed from it.  It may well be
> that after the consultation the piece will be removed anyway, but on
> the other hand, it may well be that there was no need to remove it in
> the first place -- which, in my very humble opinion happens to be the
> case here.

Unless you were the SA syscalls explicitly (and you shouldn't have  
been since we had already revised that API once without preserving  
backward compatiblity which was allowed because it was in -current  
and had not been included in a release branch), the removal of SA  
should have been completely transparent.  A newlock2 kernel and  
rebuilt libpthread is all that was needed to take advantage of the  
new 1:1 threading.