confirmed working NPTL revision?

Rob Landley rob at landley.net
Tue Sep 16 07:03:18 UTC 2008


On Tuesday 16 September 2008 01:23:37 Carmelo AMOROSO wrote:
> > 1) How platform specific is it?
>
> Fully, TLS relocations are different from one arch to another.

Ok.

> > 2) Does it actually have anything to do with nptl?
>
> Nothing, just dynamic linker, and obviously your compiler has to
> recognize the __thread keyword.

I think we've got that part covered.

> > What I'm thinking is that if TLS can be added to the main svn branch as a
> > separate chunk, that's can be considered a partial merge (brings the NPTL
> > and mainline branches somewhat closer), and it's small and separate
> > enough to go into a 0.9.30 release.
>
> Honestly, I'd do a 0.9.30 right now without delaying further as a lot of
> peoples are asking for a new release since a long time.

Works for me, except that I'm still doing mroe testing and I've got bugs to 
fix.

Since I haven't got the authority to tell people _not_ to check random changes 
into svn, what I may do is grab a snapshot of the svn archive, put it into a 
mercurial archive, call that "-rc1", and then do bugfix-only changes to it 
until I get a 0.9.30-final.

We can worry about "official" after the release. :)

> We can have a branch as a development tree for adding TLS support but
> independently from NPTL merge... I'd like to do this after .30 release.
> In this way we will have already TLS for arm/mips/sh4 as part as the
> nptl work... and it can be used as a reference implementation.

Ok.

> At this stage, having a separate branch for adding TLS support for other
> archs (which one... i386 only ?) , may be done in a separate branch or
> directly to the main stream.

I never bother with branches in subversion.  *shrug*

> > Also, rather than have _three_ threading branches (once NPTL is added),
> > I'd like to yank LINUXTHREADS_OLD before releasing a 0.9.30 if the newer
> > stuff works for everybody.  (And if it doesn't, I want bug reports.)
>
> I honestly have never used linuxthreads so I don't how it work.

Like anything else, really.

Here's a test program for threading I wrote, which passes data from one thread 
to another via a simple mailbox implementation using mutexes and event 
semaphores:

http://landley.net/hg/firmware/file/tip/sources/native/src/thread-hello2.c

It's basically "hello world, but way complicated".

> IIRC 
> there have been some issues in the past... so, unless we are totally
> sure, we need to keep the working/stable and old linuxthreads.old.

No, what we do is we keep the 0.9.29 tarball around and if people have bugs 
trying to use 0.9.30 they _report_ them to us.  If they want to use the old 
threading code, they can use the old version of the library.  If they want 
the new features, then they help us find (and fix) the new bugs.

> Remeber that, even when merged, NPTL is available only for 3 archs at
> the time being.

Who said anything about NPTL?  Right now, in 0.9.29, there's LINUXTHREADS_OLD 
and there's a second implementation of Linuxthreads that most people haven't 
been testing because they're still on LINUXTHREADS_OLD.  There's not much 
point in having two of these right now, and adding NPTL would make _three_.  
I'd like to keep it to no more than two, which means I need to yank one 
before NPTL goes in.

> > Rob
>
> Comments are welcome.
> Carmelo

Rob



More information about the uClibc mailing list