[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