On Monday 23 November 2009 16:53:21 Austin Foxley wrote: > On 11/23/2009 02:38 PM, Rob Landley wrote: > > On Monday 23 November 2009 10:54:10 Austin Foxley wrote: > >> On 11/23/2009 08:43 AM, Mike Frysinger wrote: > >>> it hasnt been put up for merging before. so either you can review the > >>> pending branch, or you can sit back and wait. > >> > >> FYI, I didn't post it as a patch series, because a lot of the commits > >> are bigger than the list limit (100k). Refer to this email if you want > >> to help review: > >> > >> http://lists.uclibc.org/pipermail/uclibc/2009-October/043146.html > > > > I'm happy to look at patches. That email contains no patches. It > > contains no URLs to patches. It contains no URLs to a patch viewer in a > > source control system. It contains no instructions on how to get git to > > spit out whatever random branch you created from wherever it lives now. > > There are plenty of ways to get at it. Here is one: > http://git.busybox.net/uClibc/commit/?h=nptl&id=<PUT GIT HASH HERE> > > So for the first commit in that email it would be. > http://git.busybox.net/uClibc/commit/?h=nptl&id=c68d0fa
Cool. That one adds a new nptl directory where sjhill imported a subset of the glibc cvs repository from may 6, 2005 (as described in libpthread/nptl/README.NPTL). It doesn't touch anything outside that new directory, so really can't break anything else. (Unless the makefile is listing directory contents and descending into them blindly, which I wouldn't put past it. Even so, this is infrastructure in search of a user, interesting only because of later patches.) It's 626 files, 55k lines, and the actual code has "glibc" written all over it. Things like: +/* How to declare function which gets there parameters. */ +# define STACK_VARIABLES_PARMS void *stackaddr The comment that manages to be completely unenlightening. Is that a typo for "their" parameters or is there such a thing as "there parameters"? (I know what a "here document" and a "this pointer" are...) Under sysdeps there are eight architecture subdirectories (alpha, arm, i386, mips, sh, sparc, powerpc, x86_64 plus a "generic"), but it also has "pthreads" and "unix" at the same level as if those were hardware architectures. Then all the interesting stuff under "unix" is in the unix/sysv/linux directory, as if there's not only going to be NPTL for some platform other than Linux, but for a _lot_ of platforms other than Linux. And of course at this level, they _repeat_ the architecture-specific subdirectories for all those hardware targets, and add a "bits" subdirectory too because you can't ever have _just_ architecture subdirectories without mixing them with something else at the same level. I'm going to go re-read http://people.redhat.com/drepper/tls.pdf and http://people.redhat.com/~drepper/nptl-design.pdf before trying to make sense of much more of this. But for the moment I'm just going "what a steaming pile of glibc" and moving on to the next commit... Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
