Linux kernel compatability

Andrew Gallatin gallatin at cs.duke.edu
Fri Jan 7 15:15:22 UTC 2011


This looks fantastic!

Jeff Roberson [jroberson at jroberson.net] wrote:

> I have seen that some attempt at similar wrappers has been made elsewhere. 
> I wonder if instead of making each one tailored to individual components, 
> which mostly seem to be filesystems so far, should we put this in a 
> central place under compat somewhere?  Is this project doomed to be tied 
> to a single consumer by the specific nature of it?

I'd prefer to see it in a central place so that other projects could
add to the interfaces.  For example, I've long wanted to get the V4L
DVB tree compiling on FreeBSD, but I've never had the time to start
the project.  I imagine it has just gotten 90% easier.

> Other comments or concerns?

What version of the linux kernel do you target?  I've just been
browsing the SVN repo, but I did not see a linux/version.h
with a #define LINUX_VERSION_CODE in it.  That suggests there 
is no chance of getting "simple", single file character
drivers with build instructions like 
	make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd` 
to work. I guess there a more complex glue layer for building?

For people complaining about linux API churn -- there is a stable
linux KABI via RHEL.  Each major RHEL release has a symbol whitelist
that they promise to maintain binary compat for across the lifetime of
the major release (many years).  I honestly think the "holy grail"
would be to implement enough of the RHEL6 KABI that you could just load
binary linux drivers built on RHEL6 the same way we load NDIS drivers.

BTW, is OFED KABI compliant on RHEL? Eg, can you build an OFED DUT
that will work across RHEL revisions, or is it tied to symbols that
are not on the kabi whitelist?

At work, I maintain our linux driver (and FreeBSD & all *nix drivers).
For a "simple" 10G NIC, we're at about 1K LOC for shims to allow us to
compile on later 2.4 and all 2.6 kernels.  So I'm impressed at "just"
10K LOC for a shim layer between FreeBSD & Linux.

ESX uses slightly modified linux drivers via a shim layer.  So there
is a precedent for this & they are a much fatter GPL target. FWIW,
I've often wished for a native ESX interface, since their shim layer
is "not quite" linux, and takes features from different versions.  I
don't see us dropping native FreeBSD support even if the shim layer
was as good as ESX's.

Drew


More information about the freebsd-arch mailing list