RE: Using kernel headers that are not for the running kernel

[David Schwartz]

> I have a little distro that I am trying to upgrade to 2.6.x.

	Okay.

> The problem is that when I use the headers for 2.6.x, glibc 2.2.5 won't
> compile.  Eventually I want to upgrade glibc/gcc, but not at the moment.
> If I use the headers from 2.4.26 for the system, but just compile the
> 2.6.7 kernel, things do compile fine for everything.

	You should not be using the kernel headers to compile glibc.

> This distro is small, and I can rebuild the entire thing in about 90 mins,
> so if I change the kernel (or really anything that has other deps), I just
> rebuild the entire thing to make sure everything is in sync.

	The running kernel should not be in sync with glibc.

> I see that a lot of distros use a separate package for the kernel headers,
> which do not necessarily coincide with the running kernel.

	Right, there is no reason they should.

> I am wondering what (if any) are the side effects of doing this are,
> especially when the kernel versions are so different.  I was thinking that
> there may be issues with some progs if the prototypes for certain kernel
> functions weren't the same.  However people are doing it and it does seem
> to work, but I am wondering how it fends for stability.

	It creates a stable system. Things become much less stable if you mess
around with all of userspace just because the kernel changes. There is no
reason user space should be in sync with the running kernel. User space
should be stable.

	The later the kernel headers you use in user space, the less compatability
you will have with earlier kernels. A program compiled with 2.4.26 header
files should work with 2.6.x, but not vice versa. When new kernel interfaces
are added, the old ones are retained to keep compatability with user space,
but programs compiled against the newer headers may fail to work with older
kernels that lack the newer interfaces. Of course, user space programs
compiled against the older kernel header files can't get the advantages of
the newer interfaces.

	The kernel-user interface is supposed to stay stable, so you shouldn't need
to make significant user space changes when you upgrade the kernel. Only
specific applications that need to get specific new features that require
changes to the kernel-user interface need to change. It has been a very long
time since compiling user space programs against the header files for the
kernel you happened to be running was considered good practice.

	DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/