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