status of 0.9.30 release

Rob Landley rob at landley.net
Fri Sep 26 01:07:06 PDT 2008


On Friday 26 September 2008 02:48:16 Bernhard Reutner-Fischer wrote:
> On Fri, Sep 26, 2008 at 02:17:30AM -0500, Rob Landley wrote:
> >Removing LINUXTHREADS_OLD might be a good idea.  (This still has nothing
> > to do with NPTL.)  Having two is silly, and anything that's wrong with
> > the newer linuxthreads should be _fixed_ before NPTL goes in. 
> > Eliminating unnecessary duplication is always a plus, and removing code
> > where possible is what uClibc is all about, really.
>
> There is no point in removing linuxthreads or linuxthreads.old in the
> 0.9.30.x series.

There are two pointlessly redundant versions, which theoretically serve 
exactly the same purpose, and not enough bandwidth to maintain both.

> When NPTL is merged (after the .30 release), i.e. for 0.9.31 or 0.10.0
> or however its version will end up as, you're free to update and fix
> the normal linuxthreads so it works at least for i386 and _after_ that,
> we could remove linuxthreads.old.

I'm told that the normal one does.  The normal one is what I plan to test and 
submit fixes for as I'm regression testing -rc1.

If anything _is_ broken, we can obviously look at the .old version out of svn 
to see what changed and how to fix it.  But the problem is that we'll have a 
limited tester base before release (especially after such a long lag between 
releases that most of them have stopped paying attention), and I'd like to 
have them all testing the same thing.  Thus, having one version of 
linuxthreads to test.

> Of course you're welcome to improve 
> NPTL to provide fine-grained option à la "Just TLS yes/no".

At this point, that's not a 0.9.30 issue.  It's a new feature, and the last 
thing we need to do is hold up for new features.

> That would 
> certainly be nice (of course i know zilch about threads nor do i think
> that i need them) and perhaps would allow for deleting both of the 2
> thread impls that are currently in trunk, dunno.

I was an OS/2 programmer for about 5 years, I used to be totally immersed in 
threads on a daily basis.  I haven't done nearly as much with it recently, 
but I still know the theory and can do simple smoke testing.

The really intermittent problems won't be found by us, they'll be found by 
people testing their own complex loads against them out in the wild.  Hence 
the need to get all of them testing the same version.

(We could also keep linuxthreads.old as the one version of linuxthreads, but 
that seems counterproductive.  I'm told most of what changed was upgrading to 
be closer to what glibc has now.)

Getting linuxthreads.new working for everybody counts as bug fixing.  The only 
reason to keep linuxthreads.old is if linuxthreads.new is buggy on somebody's 
load, and A) that's something we want to hear about and we won't hear if they 
don't try it, B) they still have 0.9.29 until we fix said bug so they can use 
0.9.30.1.

> cheers,
> Bernhard

Rob


More information about the uClibc mailing list