26.03.2006 23:09, Rob Landley wrote/a écrit:
On Sunday 26 March 2006 9:31 am, Eric Piel wrote:
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.
You know all the stuff that's marked __user? It's all kernel ABI. Having it
defined in two places invites version skew, and the kernel needs it too
because the kernel is parsing the stuff sent in by userspace and filling it
out to send back to userspace.
Lots of syscalls and ioctls and such pass a structure back and forth from
userspace to the kernel and back, right? Doing a stat() fills out a
structure, doing an losetup fills out a structure, and so on.
Userspace needs to know what's in this structure. It may be wrapped in a libc
function that fills out a different structure from the kernel structure, but
the data that goes back and forth between the program and the kernel has to
be defined in a header somewhere so the libc knows what the kernel's sending
and the kernel knows what the libc is sending. (And for those functions with
no libc wrapper, the user program needs to know the structure directly,
somehow.)
Having a data-marshalling ABI structure defined in two places invites version
skew. Userspace needs access to this (at least to build a libc), and the
kernel needs access to this, because it's a _communication_mechanism_. You
can't have a communication mechanism that's only defined at one end.
Well, that's half true. Indeed, in general, having two separate
definitions invites version skew. However, in this particular case, it's
slightly different: because the principle of the ABI is to be stable, or
more exactly _compatible_. This means that if one definition was right
at some point in the time, it should always still be true ten years
later. At worse, the ABI can be extended, but never changed. If the
specification (KABI) and the implementation (Linux) are not compatible
it means the kernel developers screwed up, not that the KABI maintainers
haven't updated in time.
Of course, next to the theory, there is the reality. Some part of the
ABI has already be changed (broken) in the past (like the alsa ABI,
IIRC). In such case the KABI maintainers will have to handle the changes
as promptly as possible, but the responsibility will be held by the
kernel developer who has opted for breakage.
The real problem of sharing the same headers between kernel and KABI is
that it will end up by having to re-implement the "#ifdef __KERNEL__"'s.
Have a look at Kyle's second patch "Generalize fd_set handling across
architectures". Some headers had a different version of the __FD_*()
macros depending on the compiler. That's something you may want to have
in the implementation but definitely not in the specification. In this
situation, Kyle handled it nicely by writing versions compatible with
any compiler. Good looking solution inside the kernel will not always be
an option. IMHO, if KABI and the kernel share the same headers, it's
just a matter of time before someone introduces an "#ifdef
__KERNEL__"-alike mechanism, exactly what we've been trying to remove.
Eric
-
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]
