On Sun, Mar 26, 2006 at 06:52:05AM -0500, Kyle Moffett wrote:
> On Fri, 24 Mar 2006 17:46:27 -0500 Kyle Moffett <[email protected]> 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.
Hi Kyle.
Been watching this thread evolve for a while - and contributed a little
myself.
But I fail to find a rationale for the selected approach.
There are at minimum the following options:
1) Go through current set of headers and sanitize them - using
__KERNEL__ to identify kernel only stuff.
2) Keep user space interface (KABI in your term?) in include/ and slowly
move kernel specific definitions somewhere else. This has the great
advantage to keep backward compaitibility.
3) 'Preprocess' include/ and generate a set of KABI files based on
current set of (cleaned up) kernel header files.
'Preporcess in '' because a C-preprocessor will not be sutilable.
4) Introduce a virgin KABI (your approach). The virgin KABI has no users
today and does in no way preserve backward compatibility.
Can you try to explain why the virgin approach is superior to the
others.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
