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

[Krzysztof Halasa]

"David Schwartz" <davids@xxxxxxxxxxxxx> writes:

> 	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.

Kernel headers should and in fact are stable WRT common userspace
interface. If they aren't, you're forced to recompile the userspace
anyway.

BTW: it's ok to compile things like glibc against new kernel headers
(say, 2.6.x) and use the resulting library with older kernels (as old
as 2.2 I think). In fact it's the preferred way to compile glibc.
You can disable support for older kernels with glibc/configure
--enable-kernel=VERSION --enable-oldest-abi=ABI.

> 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.

Sure. Examples: ioctls for configuring the system.

> 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.

I think at this point we have to create include/abi (or api) as a part
of the kernel. The mess with distributions-provided "glibc kernel
headers" must at last be cleaned.

Should no one have time for doing that I'm going to start.
-- 
Krzysztof Halasa, B*FH
-
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/