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 _______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc