Date: Fri, 7 Jan 2011 10:15:20 -0500 From: Andrew Gallatin <gallatin@cs.duke.edu> To: Jeff Roberson <jroberson@jroberson.net> Cc: arch@freebsd.org Subject: Re: Linux kernel compatability Message-ID: <20110107151520.GA9925@grapeape2.cs.duke.edu> In-Reply-To: <alpine.BSF.2.00.1101031017110.1450@desktop> References: <alpine.BSF.2.00.1101031017110.1450@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
This looks fantastic! Jeff Roberson [jroberson@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110107151520.GA9925>