[RFC][PATCH 1/2] Create initial kernel ABI header infrastructure
Kyle Moffett
mrmacman_g4 at mac.com
Mon Mar 27 02:27:42 CEST 2006
On Mar 26, 2006, at 16:26:01, Sam Ravnborg wrote:
> On Sun, Mar 26, 2006 at 03:39:32PM -0500, Kyle Moffett wrote:
>> I'm not entirely sure I understand this bit. The idea behind this
>> kabi stuff is precisely to split out portions of the headers so
>> that both userspace and kernelspace can get at them; to designate
>> specific items as "userspace clean" by putting them in kabi;
>> everything else need not care at all, and all those headers would
>> remain in include/ linux where they are now. No sense moving
>> _everything_ in include/ around, we just want the parts that
>> userspace needs too.
>
> There are today a great number of users of the existing kernel
> headers. Introducing a new namespace for the userspace suers will
> leave them in a dilemma where they have to support kernels before
> kabi, and kernels with kabi. That alone will limit the acceptance
> of this.
I tried to talk to this in my other email, but for emphasis; I'd like
to do two things:
1) Preserve compatibility with <linux/*.h>, so that old programs
still work fine
2) Cause <kabi/*.h> to work on any distro, and kernel, not just
kernel released after it is introduced. In practice this means that
a distro could just package up the kabi headers and install them in /
usr/include. A package that is altered to compile against only
__kabi_* would be able to use information about which syscalls and
structures are available in each version to either handle different
kernels at runtime or have a configure-time kernel version specified
by the user.
> Keeping include/linux for the kernel ABI will allow us NOT to break
> existing users and it will allow a stepwise apporach at the same time.
I completely agree. If you'll notice the patches I submitted were
quite careful to preserve the exact same semantics for the linux/*.h
headers, both in the interests of not breaking the kernel _and_ in
the interests of allowing userspace to still include <linux/
types.h>. IMHO, we should try to get the interface compatibility
crap _out_ of linux source tree and into a separate package which
depends only on the cleaned-up interface specification (IE: kabi/*).
Cheers,
Kyle Moffett
More information about the llh-discuss
mailing list