Bernhard Reutner-Fischer wrote: > On Sat, Dec 20, 2008 at 09:37:04AM +0100, 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. >> >> 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. >> 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. > > A config option for TLS is a good idea, yes. >
Ok (I'll do this in branch first) >> We could fix bugs in NPTL code (i.e. signal handling changes) directly >> working on 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. >> >> 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) > > can you mv libm/sh/fpu/* libm/sh/ ok. (I'll do this in branch first) >> - 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. >> >> Please comments are welcome. > > include/sched.h adds __clone, __clone2 unconditionally; needs fixing ok (I'll do this in branch first) > extra/Configs/Config.in > bool "Native POSIX Threading (NPTL) Support" > should better read "Native POSIX Thread Library (NPTL) Support" > for consistency. > ok (I'll do this in branch first) > ldso.c has some changes that seem to be unneeded (struct stat st; I thought this was removed. ok > in _dl_get_ready_to_run(), the declaration of was_tls_init_tp_called > is not C89, this seems to happen alot in the tls code and needs fixing > first). ok. I'll look at > socketcalls.c too mixes declaration and code and needs to be fixed. > ok > How do you want to proceed? > Can you prepare clean, C89, separate patches for > - FUTEXes (with a config knob) > - TLS (also with a config knob) > Yes it could be a good starting point. These are not overlapping piece of code, configurable, that should not conflict with any other current work (i.e code size reduction in string function and so on). I also would add the whole nptl/nptl_db tree as is since the beginning With these 3 steps we could import in the trunk the bulk of the nptl branch. After that we can start with the remaining (more complex) part. Cheers, Carmelo _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
