lkml.org 
[lkml]   [2006]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC][PATCH 1/2] Create initial kernel ABI header infrastructure
Date
On Mar 26, 2006, at 15:05:37, Sam Ravnborg wrote:
> On Sun, Mar 26, 2006 at 06:54:16AM -0500, Kyle Moffett wrote:
>> Create initial kernel ABI header infrastructure
>>
>> diff --git a/Makefile b/Makefile
>> index af6210d..8e9045a 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -787,13 +787,15 @@ ifneq ($(KBUILD_SRC),)
>> /bin/false; \
>> fi;
>> $(Q)if [ ! -d include2 ]; then mkdir -p include2; fi;
>> + $(Q)if [ ! -d include2/kabi ]; then mkdir -p include2/kabi; fi;
>> $(Q)ln -fsn $(srctree)/include/asm-$(ARCH) include2/asm
>> + $(Q)ln -fsn $(srctree)/include/kabi/arch-$(ARCH) include2/kabi/arch
>
> No - we do not want another symlink.
> Create something like:
> include/i386/kabi-asm/ <= i386 specific files
> include/kabi/ <= general files
>
> Then we can do:
> LINUXINCLUDE += -Iinclude/kabi-$(ARCH)
> And the following would work like expected:
> #include <kabi/foo.h>
> #include <kabi-asm/foo.h>

Hmm, I see where you're going with this. Thanks for the tip!

> But this leaves all existing users in the dark cold. So a more
> involved approach could be to take the opposite approach. To
> dedicate an area for kernel only header files and make sure this
> directory is searched _before_ include/

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.

> And we have so many users of include/linux today. They do not need
> a _kabi_ prefix so let it go.

_Exactly_ the point. I'd like to leave 99% of the kernel code
alone. Userspace doesn't work with the headers in the stock kernel
as-is, so I see no problem with working to provide a clean source ABI
even if it's partially incompatible with the old source ABI. The
binary ABI would stay the same, though, and I'd try to fix the old
source ABI where possible.

I think I'll try something like your original proposal:
include/kabi/ <= Userspace-clean generic ABI includes
include/$(ARCH)/ <= New arch-specific include directory
include/$(ARCH)/kabi-arch/ <= Arch-specific ABI includes

Then the following Makefile snippet:
LINUXINCLUDE += -Iinclude/$(ARCH)

And then in the header file:
#include <kabi-arch/stddef.h>
#include <kabi/types.h>

It would also be possible to move files from include/asm-$(ARCH) to
include/$(ARCH)/asm if desired, but that's a little offtopic for the
kernel-ABI headers project I'm working on right now.

Thanks for the advice!
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/

\
 
 \ /
  Last update: 2006-03-26 22:42    [W:0.143 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site