: having own copies of kernel header files is a very *bad* idea IMHO.
: either I have to add tons of #if this_kernel_vesion etc. or I have to
: change [many?] application sources if the kernel header files change
: (e.g. one more entry in a structure...)
I think I disagree.
With private copies of the kernel includes as they were for
version x.y.z you can compile a program that works for kernel
x.y.z and hopefully some earlier and later kernels as well.
The program will compile cleanly.
With actual kernel includes used, one notices that the program
no longer compiles under x.y.z+1 because someone changed something
and forgot to protect it with #ifdef __KERNEL__
or because of namespace pollution, or because the kernel version
of some structure changed.
This happens all the time and is a constant source of nuisance.
Subtle bugs are introduced because something that used to be an
int is an unsigned int in today's kernel includes.
There is some effort to maintain binary compatibility -
probably the locking stuff is the main reason why old programs
do not work under modern kernels - it is the main reason I cannot
use 2.1.* on some machines.
But the kernel source is in a constant state of flux - nobody
who maintains a software package wants to be dependent on the
state of the kernel source.
And if the kernel interface really changed, then yes, you *do*
want to have #if this_kernel_version in your program/includes.
(Or, even better, detect the change dynamically, and have both
the old and the new versions in your include file.)
Look at how recent versions of mount handle nfs_version.
Andries