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

From: Kyle Moffett
Date: Sun Mar 26 2006 - 19:10:18 EST


On Mar 26, 2006, at 15:55:51, Rob Landley wrote:
On Sunday 26 March 2006 7:34 am, Kyle Moffett wrote:
Well I guess you could call it UABI, but that might also imply that it's _userspace_ that defines the interface, instead of the kernel. Since the headers themselves are rather tightly coupled with the kernel, I think I'll stick with the KABI name for now (unless somebody can come up with a better one, of course :-D).

Ok, question, using an example I'm familiar with. What's affected by the prefix?

We eventually got it all untangled. Now we check if we're on 2.6 and if so use the 64 bit API (which is stable on 2.6), and otherwise use a copy of the 32 bit structure that predates __kernel_dev_t being renamed. And we trust the darn kernel headers to supply the types for us, because there's just no alternative.

My question is: will your new approach work with our existing code, or are you saying we need another #ifdef to check for yet another gratuitously incompatible name, ala _kabi__kernel_dev_t?

No, no need for a new #ifdef, at least not for a long time if you don't want to. My plans for the immediate future are only to touch files that are currently broken with respect to !__KERNEL__, and linux/loop.h isn't. When I do get to it, my plan is to bring the parts that userspace needs into kabi/loop.h, named as __kabi_*, however linux/loop.h will define the new symbols to their old names for compatibility with linux code and userspace code that happens to be using those interfaces, so you still won't need to change anything. Hopefully this would also mean that if the shipped linux/ loop.h is currently broken for your uses, I would be able to fix it so you don't need a customized copy at all.

If you _did_ decide to switch busybox to use the __kabi_ symbols, you would be able to take advantage of the fact that the same set of kabi headers (which don't include kernelversion.h) would work unmodified for kernels all the way back to 0.99, as long as you base your decisions of what features are available on either a dynamically- detected version or a pre-configured minimum version from the user. I'm assuming here that it's possible to compile a busybox that works on a 2.2 or 2.4 kernel even using linux-libc-headers 2.6.*, as long as the user indicates such.

This is just an example. There is currently no existing program out in userspace that is tries to talk to the kernel using names with _kabi_ prepended to them, that I am aware of. If you're adding this prefix, you're writing a brand new interface which currently has exactly zero users. Is this the intent?

I'd like this project to have a twofold purpose. First, in the short term I want to fix up the general __KERNEL__ vs !__KERNEL__ brokenness in include/linux and clean up and document which APIs are userspace ABI by moving them to include/kabi. If that first part works, then in the very _long_ term, (on the order of a couple years or so) I would like to encourage larger projects like klibc and GLIBC to migrate to using *only* the include/kabi headers to avoid namespace pollution and allow kernel devs to rearrange and adjust the linux/* headers as they see fit without caring about breaking external programs.

Once the libcs are using kabi/*, GLIBC can pick up a set of linux/*.h "emulation" files based on kabi/*.h that provide all of the old source-APIs for as long as anybody cares, and Linux can go back to screwing around with its header files in any way that it pleases (just as long as it keeps ABI stuff all in kabi). One of my major goals for this rework is to ensure that the kabi/*.h header files actually define the _ABI_ going back to the very early releases of Linux. As Linus said, it's an ABI, which means that adding new features is OK, but removing them is bad, so I'll try to make sure it's _perfectly_ _ok_ to use a 2.6 kabi/ on a 2.0 kernel. It should also be perfectly ok to use a 2.6 kabi/ on a 5-years-down-the-road 2.8 kernel as long as you restrict yourself to the subset of features that were available in 2.6.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/