Re: [RFC][PATCH 1/2] Create initial kernel ABI header infrastructure

[Kyle Moffett <mrmacman_g4@mac.com>]

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



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