lkml.org 
[lkml]   [2006]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 0/2] KABI example conversion and cleanup
26.03.2006 13:52, Kyle Moffett wrote/a écrit:
> On Fri, 24 Mar 2006 17:46:27 -0500 Kyle Moffett <mrmacman_g4@mac.com> wrote:
>> I'm working on some sample patches now which I'll try to post in a
>> few days if I get the time.
>
> Ok, here's a sample of the KABI conversion and cleanup patches that I'm
> proposing. I have a few fundamental goals for these patches:
> 1) The Linux kernel compiles and works at every step along the way
> 2) Since most of the headers are currently quite broken with respect to
> GLIBC and userspace, I won't spend much extra time preserving
> compatibility with GLIBC, userspace, or non-GCC compilers.
> 3) Everything in include/kabi will have a __kabi_ or __KABI_ prefix.
> 4) Headers in include/linux that need the KABI interfaces will include
> the corresponding <kabi/*.h> header and define or typedef the
> necessary KABI definitions to the names the kernel wants.
> 5) The stuff in include/kabi/*.h should always be completely independent
> of userspace/kernelspace and not require any includes outside of
> <kabi/*>. This means that the only preprocessor symbols that we can
> assume are present are those provided by the compiler itself.
Hello,

I completely agree with rules 1, 2 and 5. However, IMHO rule 4 should
just be the inverse of rule 5: The stuff in include/linux should always
be independent from KABI (and userspace of course). Simply because the
way we _implement_ things in the kernel has to be different from the
things that we _specify_ in the kernel ABI. They just append to be both
written in C language, but it's not a reason to mix them. The kernel
developers has to be free of doing any kludge, clever things,
compatibility workarounds without affecting the userspace applications.
Otherwise, you'll end up with another include/linux after few months!
Separating the implementation and the binary specification has the
additional advantage that if some kernel hacker mistakenly change the
ABI, it's easy to say : "see, after your commit xxxxxxxx, the linux
header and the kabi header are semantically different. You did something
Wrong".
As for rule 3, if you have independent headers, this should be much less
necessary. Additionally, keeping all the names identical to what they
are already called will allow userspace to just use include/kabi/ as the
/usr/include/linux/ directory. Avoiding smelly things like:

linux/foo.h:
#define __kabi_foo foo
#include <kabi/foo.h>

That was my 2 cents :-)
Regards,
Eric

-
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 16:34    [from the cache]
©2003-2011 Jasper Spaans