>Good. Because everything under __KERNEL__ belongs to the kernel and is
>subject to change without notice. If you really need something from that
>area - you've either
> a) found a bug or
> b) missed a portable way to achieve your goal.
>Userland should never, ever define __KERNEL__, unless it's consent with
>breakage upon the upgrade from 2.2.18-pre9 to 2.2.18-pre10-pre1.
OK, so suppose there really was a <linux-rtc.h> that came with
glibc. Suppose I compile a program that uses it, and run it under
foo.bar.whatever. Then foo.bar.whatever+1 comes out. It turns out that
there was a change in the kernel header that directly alters the way
the functions and values declared in <linux/rtc.h> there should be used.
What happens when I notice this change in the kernel source or on this
list, and then decide I need recompile my program ? Nothing! It
doesn't use the new headers, it uses the old ones that came with
glibc. I run it, and it crashes, possibly with an oops too.
Is that what you want to have happen ? People who write programs that
interact with devices drivers directly *know* that their success
relies on using the correct headers. They know that if the new kernel
version altered the API for a given driver or subsystem, they will
need to recompile (and possibly alter code). Telling them "never,
ever, ever use a kernel header" creates a false sense of safety. "Keep
your own copy of the headers" is telling them to cache a snapshot of
the kernel header, one which may become out-of-date without them
noticing, unless they look really carefully. And if they *do* look
really carefully, they will end up simply copying (i.e. using) the
contents of the current <linux/foo.h> file.
User-space/kernel interactions are a dialog. If both sides are not
using the same language, the dialog won't work. *Some* kernel header
files define such a language. When they don't change much, or they
represent abstractions that don't change much, its fine for them to be
replicated in glibc. But a lot of headers in linux/ are not like
that. Very few programs *need* to use them, but the ones that do need
to, *really* need to.
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:13 EST