>>>>> "Paul" == Paul Barton-Davis <pbd@Op.Net> writes:
Paul> OK, so suppose there really was a <linux-rtc.h> that came with
Paul> glibc. Suppose I compile a program that uses it, and run it
Paul> under foo.bar.whatever. Then foo.bar.whatever+1 comes out. It
Paul> turns out that there was a change in the kernel header that
Paul> directly alters the way the functions and values declared in
Paul> <linux/rtc.h> there should be used.
Paul> What happens when I notice this change in the kernel source or
Paul> on this list, and then decide I need recompile my program ?
Paul> Nothing! It doesn't use the new headers, it uses the old ones
Paul> that came with glibc. I run it, and it crashes, possibly with an
Paul> oops too.
And this will still happen if you have a random old binary around. If
the kernel ABI is changed one should switch to a new ioctl anyway or
use versioning in the ioctl data structure so the kernel can reject
data from an old application.
Paul> Is that what you want to have happen ? People who write programs
Paul> that interact with devices drivers directly *know* that their
Paul> success relies on using the correct headers. They know that if
Paul> the new kernel version altered the API for a given driver or
Paul> subsystem, they will need to recompile (and possibly alter
Paul> code). Telling them "never, ever, ever use a kernel header"
Paul> creates a false sense of safety. "Keep your own copy of the
Paul> headers" is telling them to cache a snapshot of the kernel
Paul> header, one which may become out-of-date without them noticing,
Paul> unless they look really carefully. And if they *do* look really
Paul> carefully, they will end up simply copying (i.e. using) the
Paul> contents of the current <linux/foo.h> file.
Wrong, if you do it right you wont see this problem and you can keep
the userland header definition.
Jes
-
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:14 EST