Messages in this thread | | | From | Rob Landley <> | Subject | Re: [RFC][PATCH 0/2] KABI example conversion and cleanup | Date | Sun, 26 Mar 2006 16:09:10 -0500 |
| |
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. - 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/
| |