On Sat, Dec 20, 2008 at 07:18:46PM +0100, Carmelo Amoroso wrote: > 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)
Great, TIA! > >>> 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) khem needs to revert his SH fenv removal 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 About all syscalls #define SINGLE_THREAD_P 1 for !NPTL which is extremely ugly. If we don't install the nptl sysdep-cancel.h then i suggest we install a cat >sysdep-nocancel.h <<x /* boilerplate */ #ifndef __SYSDEP_NOCANCEL_H #define __SYSDEP_NOCANCEL_H # define SINGLE_THREAD_P (1) # define NO_CANCELLATION 1 #endif /* __SYSDEP_NOCANCEL_H */ x to cut down on those redundant defines, or something to that effect. What do you think? >> 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. Excellent. Can you, Carmelo, please send the clean FUTEX patch to the list and then the TLS patch? TIA, _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
