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

[Rob Landley]

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