modifying kernel

[Brian Densmore]

> -----Original Message-----
> From: Jason Clinton
> 
> Brian Densmore wrote:
> > Actually use of /usr/src/linux is *highly*
> > discouraged. It is far better to use the /usr/src/linux-...
> 
> Unless we're thinking of a different kernel, the 
> /usr/src/linux location 
> is merely a standard for the location of the kernel headers used for 
> compilation of modules or programs that need the kernel headers.
> 
> Every time I upgrade the kernel I relink /usr/src/linux to the new 
> kernel sources location.
> 
And therein lies the heart of the problem. 

The glibc libraries use the headers in /usr/src/linux.

"Basically, that symlink should not be a symlink. It's a symlink for historical reasons, none of them very good any more (and haven't been for a long time), and it's a disaster unless you want to be a C library developer. Which not very many people want to be.

The fact is, that the header files should match the library you link against, not the kernel you run on.

Think about it a bit.. Imagine that the kernel introduces a new "struct X", and maintains binary backwards compatibility by having an old system call in the old place that gets passed a pointer to "struct old_X". It's all compatible, because binaries compiled for the old kernel will still continue to run - they'll use the same old interfaces they are still used to, and they obviously do not know about the new ones.

Now, if you start mixing a new kernel header file with an old binary "glibc", you get into trouble. The new kernel header file will use the new "struct X", because it will assume that anybody compiling against it is after the new-and-improved interfaces that the new kernel provides.

But then you link that program (with the new "struct X") to the binary library object archives that were compiled with the old header files, that use the old "struct old_X" (which used to be X), and that use the old system call entry-points that have the compatibility stuff to take "struct old_X".

Boom! "
 - Linus Torvolds