On Saturday 20 December 2008 09:37, Carmelo Amoroso wrote: > Khem, Bernhard
> IMO the effort required for merging new stuff (not bug but basically > cleanup, warning and so on) from trunk to nptl branch, is becoming > to huge, and it is not helping us into having a working NPTL branch > getting benefits from this. Guys are putting new changes into trunk > faster than me. I suspect you are referring to me in significant part :( sorry. > Indeed we had a lot of problems in the nptl branch due to changes > in signal handling for example (there are still few files that I did > not merge because they caused nptl branch stopping to work). > > At this stage my proposal is to start *now* putting TLS/futexes/NPTL code > into the trunk. This will not impact any architectures. I think it's the way to go. Even though it may destabilize the tree a bit, but we shouldn't be too scared of it, otherwise how new stuff will ever be added if we do? > NPTL is configurable, as well as FUTEXES (used for stdio locking). > We should probably add a config option for enabling TLS (this is currently > hard coded into the tls.h header by defining USE_TLS. > > We could fix bugs in NPTL code (i.e. signal handling changes) directly > working on trunk. Even more, others can fix bugs (especially bugs from their changes) when the code is on the trunk. > I did not expect any changes into ld.so for TLS. > We need to look carefully at cancellation handling, but this will get > benefit from having all the code into trunk, because there are more guys > looking at this than those using nptl branch. May I suggest that while you have it sorted out in your head, you write up a bit about this stuff and put the resulting docs into docs/*? This will help a lot those of us who are not deep enough in threads, TLS, cancellation, C++ throw machinery and so on. Look at it this way: instead of having code broken by, say, my changes because I don't know what cancellation is and how does it work; instead of fixing it after me or explaining it to me on the ml, you just write it up, once. After a few editions and feedback from clueless readers (me), it will be explaining this stuff well enough to prevent the above bad cases. I did something similar, see sigaction.txt and defines.txt files there. > I've also a list of suggestions from Peter Mazinger on how to wrap > cancellation handling commonly in NPTL and linuxthreads (yes Peter, > I did not forget ;-) ) > > The current status of the nptl branch is: > > - sh4: working again tested with > - uclibc testsuite > - LTP (running a 2.6.23.17 kernel from STLinux distribution) > > - arm: as you have told us, some issues using sysv hash > but working with gnu hash (it needs investigation, but it seems > to me not related to code merge) > > - mips: unknown to me. Maybe I brake while merging, even if I did > not touch any arch specific part > > From my side (I mean my uclibc work at ST) I'll release a stable 0.9.30-nptl > based on current nptl branch early next year, but I'll not keep on merging > trunk2branch stuff. > I volunteer my self for starting the opposite: branch2trunk merge now. -- vda _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
