Archaic wrote: > or better yet, does anyone see a need to include the new syscalls?
I'm surprised this question has been asked. It's Glibc FAQ material: http://sources.redhat.com/glibc/glibc-faq.html#s-1.8 And for an explanation with more details, pls see here: http://www.diy-linux.org/pipermail/diy-linux-dev/2006-March/000755.html When studying the quoted code snippet, keep in mind the __NR_ macros represent kernel syscalls which are defined in the kernel headers Glibc is compiled against. Also keep in mind the __ASSUME macros are defined in sysdeps/unix/sysv/linux/kernel-features.h. Understanding the logic of that snippet is vital to interpreting how Glibc handles this stuff. (Note: the above applies to interfaces eg: at_* functions, where there is actual code in Glibc. Stuff like inotify doesn't need much in the way of actual code in Glibc, just a header and some other bits so that Glibc is aware of the syscall). 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. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
