The correct thing to do is to NOT include linux/time.h in the first place.
Documentation should state (and probably does, in several places) that
mixing glibc and kernel include files is not generally a good idea.
The problem is that there are certain system programs that need kernel
constants. Sure, we could replicate the magic numbers and structures in
our own user-level include files, but that introduces the possibilities
that things will get out of sync, causing all sorts of problems.
So instead of using the standard glibc mantra of "mixing glibc and
kernel include files is a bad idea, and programs who need to do this
aren't our problem," let me suggest a better way (tm).
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?
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu