Messages in this thread | | | Date | Mon, 8 Feb 1999 13:41:52 -0800 | From | David Hinds <> | Subject | Re: Kernel interface changes (was Re: cdrecord problems on |
| |
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/
| |