Rob Landley wrote: > On Sunday 21 December 2008 00:57:20 Carmelo Amoroso wrote: >> Peter Mazinger wrote: >>> Hi all, >> Hi Peter, >> happy to hear from you, > > Same here. :) > >>>> 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. >>> My proposals: >>> - keep TLS and NPTL as separate options, what is now in nptl-branch does >>> not consider the possibility of having TLS with Linuxthreads >> definitively correct: it seems to me indeed that the nptl branch was not >> born with the idea of merging all together since the beginning > > Does NPTL depend on TLS? > No, NPTL needs some support from kernel (futexes) and works with 2.6 kernel and later (I don't remember exactly since from version)
TLS support is all implemented by the ld.so and needs gcc/ld support. Carmelo >>> - TLS is no option for LT old, block that possibility (as well the >>> cancellation moving to libc wont be compatible with LT old and will >>> either need LT old adaption - I would not do that, or use macros as I >>> proposed that are noops/do somethink else for LT old) >> I was actually referring to these macros you proposed times ago. > > I'm still not sure why we're keeping both LT old and LT. Yeah, the newer LT > doesn't work for some people, and they'll never try it as long as we maintain > a whole duplicate implementation. But "0.9.28" could be seen a uclibc.old > and > we don't keep the entire old codebase in each new tarball. If we did, people > wouldn't tell us if the new stuff doesn't work for them, so we can fix it. > >>> - do not allow FUTEX enabling if NR_futex is defined (it is probably not >>> even enough, it will need some newer futex in kernel, futex syscall was >>> added somewhere around 2.5.5x? iirc, but that version is not good enough, >>> maybe it will need at least a specific kernel version, you might know >>> that better) > > We support people using current 2.4 (what's it up to, .35?), and we support > people using reasonably current 2.6. A simple "is it there" test will > distinguish between those two. > > People still trying to use 2.5, or early 2.6 back before .12 or so, are in > for > a world of pain anyway. Keep in mind the guy doing 2.6.16 long term support > (adrian bunk?) gave up and rebased it a while back, because it was just too > old to be interesting. If you find the oldest version NPTL can work with is > 2.6.9, are you going to regression test against that old version? > > Yeah, lots of people have obsolete vendor only kernels with obsolete vendor > only toolchains, and they can use a vendor version of uClibc until they > decide > to push enough of their environment upstream that we can support it. > > Rob > > _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
