Re: [RFC][PATCH 0/2] KABI example conversion and cleanup

Rob Landley
2006-03-26T21:09:26Z

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.

> 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>

The #define is, indeed, smelly.

Rob
--
Never bet against the cheap plastic solution.