But as I have been pointing out, auto-taking the most recent kernel version
has at least two disadvantages: (1) it doesnt compile, (2) if it compiles,
you find that your program suddenly is broken.
No, you're wrong.
It works if (a) the kernel the header file is carefully constructed to
be backwards compatible and portable, and (b) you use the scheme I
describe to make sure you use the *newer* of either the kernel version
or the one provided in your user package.
For example, look at linux/serial.h. It was originally written to be a
publically exported file, and so it was carefully constructed so that
you *can* always auto-take the most recent version.
It requires some discipline on the part of the kernel programmer, but it
can be done. Quite frankly, I've been screwed worst by undisciplined
changes in the header files provided by glibc than I ever have by
undisciplined changes in the kernel header files. (There were people
who lost files and valuable data thanks to the llseek() screw-up.)
Should we therefore say that people should never auto-take the latest
glibc header files? Of course not.
The same is true for kernel header files. So long as they are kernel
header files carefully constructed to be compatible and to document
public interfaces, everything will be just fine. And if the argument is
that glibc programmers are somehow inherently better able to create
backwards compatible header files than kernel programmers, all I can say
is that I very much disagree with you.
- Ted
-
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/