> Let us fix the kernel header files with the appropriate #ifdef __KERNEL__
> statements so it is safe to mix glibc and kernel include files. This
> means that kernel developers will have some work ahead of us. However,
> we also need to be compatible with libc5 header files, which *do* depend
> on certain defines which normally should be kernel-only. So, we will
> need the glibc folks to define some symbol (perhaps it exists already; I
> haven't done the research yet) which is always defined in glibc header
> files, whenever something fairly standard, like sys/types.h is
> included. This will allow us to appropriate conditionalize the kernel
> header files so that the header files are both compatible with libc5
> header files, as well as glibc header files.
> Does this sound reasonable?
This is a generally good idea, and there is such a symbol (__GLIBC__,
which is the major version of the library [currently 2]). However, it does
require that libc headers be included before Linux headers -- if linux/foo.h
is included before any libc headers are included, then foo.h has no way to
know which libc is installed without including libc headers itself. This
constraint is certainly much easier to satisfy than other solutions to the
"glibc headers don't like kernel headers" issue, but unless the kernel checks
for both libc5 and glibc2 symbols like __GLIBC__ (and complains if neither is
present), then it could hide problems rather than solve them.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com