Re: Kernel interface changes (was Re: cdrecord problems on

David Hinds (dhinds@zen.stanford.edu)
Mon, 8 Feb 1999 13:41:52 -0800


H. Peter Anvin wrote:
> * Linus Torvalds has no interest whatsoever in developing such a
> plug-in ABI. Someone else is welcome to do it.

Actually, I've already done some work on writing up something like
this, for use with PCMCIA. My original goal was to overcome problems
with symbol versioning, where modules compiled *for the same kernel
version* were judged to be incompatible due to a kernel configuration
change. A number of kernel data structures depend on kernel config
options, though most of the changes are not important from the
perspective of the module: as an example, the skbuff structure depends
on CONFIG_IP_FIREWALL, CONFIG_SHAPER, and CONFIG_HIPPI. However, if a
device driver module uses only standard kernel services, these
dependencies are irrelevant and do not affect binary compatibility.

In my wrapper layer, some services are implemented by just mapping an
unversioned symbol to a versioned symbol (i.e., things like sprintf
that should not have version codes in the first place). Macros and
inline functions that depend on kernel configuration details are
reimplemented with wrapper functions: this allows me to cover up the
skbuff differences, as well as differences between SMP and non-SMP
kernels. I also implement some stub routines for optional subsystems,
so that, for instance, a module that expects APM will load whether or
not it is present, and the APM stubs just return errors.

I'm almost at the stage where I can run all of PCMCIA on top of this
layer: that would include block, character, network, and SCSI device
drivers. Layering a filesystem would be more complicated, and I don't
know enough about the VFS layer to know how to do that.

There is obviously some cost to all of this. Things that were inline
now require a function call, and there is an extra indirection for
some other things. My guess is that the overhead will be difficult to
measure in practice.

David Wragg wrote:
> CONFIG_MODVERSIONS should make this relatively easy: Any changes to a
> exported kernel function causing a binary-compatibility problem will
> change its mangled name, so the compatibility library just has to
> provide a compatibility function with the old mangled name.

I think you'll be discouraged when you try to figure out how many
different mangled names would have to be provided in your library.

In general, I've decided that CONFIG_MODVERSIONS causes more trouble
than it's worth. It doesn't *really* ensure binary compatibility,
since it can only demonstrate syntactic compatibility at the interface
level. And it trips up on differences that are irrelevant to binary
compatibility. Practically speaking, it ensures compatibility by
being so pessimistic, that even if it doesn't catch a genuinely
important semantic change, it is almost certain to find some other
irrelevant syntactic change to complain about.

-- Dave Hinds

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