confirmed working NPTL revision?

[Carmelo AMOROSO]

Rob Landley wrote:
> 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.
> 
Well, we could ship now with a -rc1. Adding bug fixes as someone have 
tests/fixes for them, and go ahead shortly with a -rc2, and so... in a 
tight loop. I do not expect to go over -rc5... just like kernel do...
> 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.
> 
... and after, yeah let's ship a stable 0.9.30.
But let's do... don't we waste more time.

> 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.
> 
It may be a solution... I' don't have the power to drop linuxthrad.old 
anyway... we need a wider agreement (Mike, Jocke, Bernhard, Bernd..others ?)

>> 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.
In this case I think you're right... we should push using it.
> 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
> 
Carmelo