Bernhard Reutner-Fischer wrote: > 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? > I was thinking to something like that. I have some old mails from Peter, where, IIRC he suggested something similar (likely already used in his linuxthreads branch). So if I'm right, I'd follow his hints.
>>> 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? > Yes, I'll try doing this during these Xmas holidays, with the limitations of not having a sh4 box for testing. When I'll be back at office, I could go faster. But yes definitively I think we must go ahead with this plan. Apologies for any delay may happen. > TIA, > Carmelo _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
