On Monday 23 November 2009 18:14:09 Austin Foxley wrote: > On 11/23/2009 03:31 PM, Rob Landley wrote: > > 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 actually can break stuff, because it ends up replacing a few syscalls > like fork, clone, getpid, etc... and some others for specific archs. If you > read the arch specific commits ( sparc: 843d561 , i386: b04c2ba ) and the > "some tweaks under libc/" commit you'll see what I mean.
I've only looked at the first patch in the series, and that first patch is adding infrastructure that isn't hooked up to anything yet. There's no config stuff, no hooks into the makefiles in parent directories, etc. Actually _using_ this infrastructure might break stuff, but and that's later patches. (Which I probably won't get to look at until tomorrow, buried in todo items today...) > Yeah this is horrible, and I've wanted to fix it, but was reluctant to > break working code for other people. We'll need to have someone for each > arch retest everything when we refactor all this mess. There's a lot of > reliance on include order across all the various subdirectories currently. I don't care how ugly the nptl code is at the moment as long as it works, and I'm more likely to find that out by building code against it and running tests than via code inspection of something the FSF has ever had anyting to do with at any point in its history. The code can be cleaned up after it goes in, I'm just trying to get a handle on it. > -Austin 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
