testing inotify

Bryan Kadzban bryan at kadzban.is-a-geek.net
Tue May 2 20:34:57 PDT 2006


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.

Yes.  However, do you necessarily need to have the kernel headers with
support for those syscalls in /usr/include/{linux,asm} after you finish
building glibc?

I don't know; I haven't tested it.  But if glibc "sanitizes" and copies
all the relevant declarations into /usr/include/sys/ (or bits/) already,
then it seems to me that the Linux kernel headers shouldn't be required.
(Unless the program is Linux-specific and low-level, like iptables or
perhaps some of util-linux.)

I'm thinking something like /usr/include/libc-headers/{linux,asm}: stick
the kernel headers in there, point glibc to that directory, and then
leave everything alone after that (except in the few places where that
directory is required by a package).  But like I said, I haven't tested
it.

But I do see problems with it: several headers from glibc-2.3.4 include
files in linux/.  For instance, sys/kd.h effectively only has an
#include <linux/kd.h> as its body; that would break if we didn't install
some form of kd.h into /usr/include/linux.  So maybe the idea's dead
already.  Dang; it was conceptually clean, at least to me.  ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20060502/f6ff338e/attachment.sig>


More information about the lfs-dev mailing list