On Wed, May 03, 2006 at 08:22:02AM +1000, Greg Schafer wrote: > > The bottom line is that you absolutely want your Glibc to be aware of new > kernel syscalls otherwise there isn't a hope in hell of them ever being > called by Glibc, even if you upgrade your kernel or user apps at a later > date. Dan is right that currently not much stuff uses the new interfaces / > syscalls but that isn't the point. If you're compiling Glibc-2.4 then you > most certainly want the latest syscall definitions available. > > Hope that helps.
It was quite informative and I thank you, but my concern is on current trunk which I'm trying to prep for a testing branch, so glibc is 2.3.6 and what I'm really curious about is if it *should* be added or not. The bottom line is that future-proofing (as Dan called-it) is not at the forefront of my mind because I tend to get more conservative as we approach package freeze. I don't foresee a problem with simply *adding* to glibc, but *modifying* how it currently works is something of a concern and I don't know which your patch does. I fully admit ignorance in this area. Basically, I need someone who knows toolchains to answer the "should or should not" question, and then I need a way to test (Dan mentioned coreutils-cvs). -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
