Messages in this thread | | | Subject | Re: Using kernel headers that are not for the running kernel | From | Krzysztof Halasa <> | Date | Fri, 18 Jun 2004 15:25:37 +0200 |
| |
"David Schwartz" <davids@webmaster.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |