On Apr 2, 2006, at 13:58:59, Sam Ravnborg wrote:
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.
1) Go through current set of headers and sanitize them - using
__KERNEL__ to identify kernel only stuff.
I'm working on this right now as step one. I see two big problems
with this approach. Primarily it leaves no distinction or
documentation for future maintenance; the sanitization doesn't last
long at all, as we've seen by trying this approach in the past.
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.
The big problem with this approach is it starts off with the
submission of a 1000-item change-the-world patchset to move all of
the completely-kernel-only patches from linux/include to linux/
kinclude; destroying all mergeability in the process and completely
serializing development. Judging from the responses on this list
when similar changes have happened before, that kind of thing is
usually considered bad.
3) 'Preprocess' include/ and generate a set of KABI files based on
current set of (cleaned up) kernel header files. 'Preprocess in ''
because a C-preprocessor will not be suitable.
I got the idea of preprocessing, but your sentence seems to have
gotten mangled somewhere. Any chance you could clarify? From what I
can see by looking through the current headers, preprocessing will
not solve some of the duplication I'd like to try to clean up. One
example being the duplication of bitops in various macros all over
the place, FD_SET/FD_CLR/FD_ISSET being a prime example of that
duplication. It would be really nice to be able to implement those
in terms of __set_bit, etc, however those macros themselves must be
made userspace-clean, including adding C89-compat macros for non-GCC
compilers and other mild ugliness, even though they'd never be
directly exposed for user programs.
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.
Your "#4" does not accurately describe what I feel I'm trying to do.
In my first set of patches I'd like to create a set of KABI headers
(recently I've been considering sticking them under "linux-klib" or
similar) which provide a set of useful standards-clean compiler-
independent typedefs, macros, and inline functions to both the kernel
_and_ whatever ABI headers we decide to use. (working on that now)
Those headers would _not_ be for use directly from userspace, but
only from within the kernel and any in-kernel ABI headers. As a
result, since they would be either shipped with the kernel which
compiles against them or installed with the KABI headers which depend
upon them, developers would be gleefully free from any obligations to
maintain a stable interface within the linux-klib headers (although
the code itself should be mostly C89 compliant).
As I do that I would like to adjust the kernel headers to use those
klib includes, hopefully alleviating some of the unusual include-
cycle problems in various headers (like the asm/posix_types.h wanting
to use asm/bitops.h for FD_SET operations, which in some
architectures indirectly includes asm/posix_types.h). Along with
that process I would be fixing up __KERNEL__ wherever they seemed
misplaced. Afterwards, I would try to clean up the actual guts of
the ABI (like FD_SET, for example), I would migrate that to include/
linux-kabi headers or similar, trying to contain all the C89-compat
code and macros for non-GCC compilers in include/linux-{kabi,klib}
For future maintenance it would hopefully provide a clean and easily
noticeable break between "You can modify include/linux as much as you
damn well please" and "This patch touches include/linux-kabi, let's
check it carefully for ABI breakage." I'd like to propose this as a
natural extension to Greg KH's ABI documentation, sequestering the
more sensitive code into a separate directory where it may be more
carefully watched and documented. Feel free to continue to criticize
and dissent; even if it's eventually determined that my idea won't
work, hopefully some other useful ideas will come up in the discussion.
Thanks for the comments!
Cheers,
Kyle Moffett
-
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]
