Denys Vlasenko wrote: > 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. > Not only ;-), but I cannot stop others from providing their support, otherwise we will never progress... so please go ahead with your plan.
>> 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. > Fine > 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? > I agree with you >> 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. > It needs some extra efforts, but yes I think it's something useful. I'd start firstly with adding code, otherwise we could delay merging again. > 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'll look at. >> 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 > Thanks for your comments. Carmelo _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
