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

Rob Landley
2006-03-26T20:56:20Z

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?

The busybox code for associating loopback devices with files was a problem for
_years_. The standard advice was not to include linux/loop.h, but instead
cut and paste the structure out of the header into your own code.
(Apparently, you're allowed to be uncomfortable if somebody suggests that
this is the right way to get portability between bsd/cygwin/linux, but
between 2.4 and 2.6 it's best practices. Ok.)

Unfortunately, the cut and paste approach turned out to be incredibly painful
because busybox needs to be portable between hardware platforms and between
kernel versions.

Problem 1: The actual type of __kernel_dev_t varies between
x86/arm/alpha/ppc/etc. Any attempt to define our own loop ioctl structure
meant we needed to either use the kernel-defined data type for this, or have
an #ifdef forest for every possible platform somebody might want to build
busybox on. (This was exploded into a mess instantly.)

But using the kernel kdev_t type sucked too, because between 2.4 and 2.6 it
got renamed to old_kdev_t so then we needed #ifdefs to check the kernel
version of the headers we'd imported to see which name it was using. (And it
still broke anyway in strange various corner cases depending on which distro
people were building under.)

We wandered through dozens of different approaches trying to avoid "#include
<linux/loop.h>". We had #ifdefs for glibc and #ifdefs for uclibc... It was
terrible. About half the suggestions got checked into the tree at various
points:
http://www.busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/libbb/loop.c?rev=14554&view=log

There were more that merely showed up on the list...

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? Because I _really_ don't want to
go there. Nobody will be able to build existing versions of busybox (at
least the mount/umount/losetup commands) against your new thing. New
versions that actually depended on _kabi_blah wouldn't build on any older
distros unless we add another #ifdef...

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?

> Cheers,
> Kyle Moffett

Rob
--
Never bet against the cheap plastic solution.