Linux kernel compatability

Chris BeHanna chris at behanna.org
Tue Jan 4 19:29:37 UTC 2011


On Jan 4, 2011, at 12:18 , Robert Watson wrote:
> On Mon, 3 Jan 2011, Jeff Roberson wrote:
> 
>>> Those where there are substantial differences, we should only have one compat layer, not one for each driver.
>> 
>> I would like this to be the case.  So we can converge on something complete. There are of course big differences between minor linux kernel revisions and that poses problems.  However those should be easier than the bsd/linux differences.
>> 
>> I think my proposal is to move these files to a more generic location so they are more visible and available to other projects.  Maintainers of individual kernel ports would have to decide if they want to use what is there.
> 
> I think it's worth making a comparison with how we handle our Open Solaris shim parts, found (largely) in opensolaris.ko, which supports Solaris-derived features such as DTrace and ZFS.  It is forced to address header location issues, license isolation issues, etc, and there may be some useful lessons there.
> 
> There are also some potentially relevant problems: for example, in a formal sense, what version of an OS's KPI do we track?  I'm no expert on opensolaris.ko, but my recollection is that we had a problem for a while where our versions of DTrace and ZFS did not come from the same version of Solaris. This even though the Sun (now Oracle) folks put a lot of work into stable kernel programming interfaces for dervice driver authors, etc.  The Linux community is less well-known for its efforts in this area, and have faster-moving KPIs.  Do we think there's sufficient KPI stability there to have a linux_kpi.ko (or whatever) that can serve more than one major consumer? Or is it sufficient to say that all Linux-derived code should track one Linux kernel version?
> 
> [...snip...]

	Please forgive me for intruding, but I have some experience with this that you may find valuable.  In a past life, I worked at a storage company, where my main area of responsibility for some years was porting our out-of-tree file system kernel module across several Linux distros on several architectures, a feat which would not have been possible without a very large kAPI abstraction layer and a clever mechanism for cross-building different kernel versions on the same machine, in the same build output tree.

	I would say that you want to pick a major release of one or at most two major commercial distros (I'll pick on Red Hat Enterprise Linux and the enterprise SuSE for illustration), and track the major releases of them that correspond to roughly the same Linux kernel version, and then STICK to that for the life of a given FreeBSD release stream.  Commercial vendors backport fixes into their otherwise-fairly-stable major releases, which minimizes your pain. There are still some changes here and there along the way, and you have to decide how many kernel config options you are willing to support (I'd suggest the default SMP, maybe the default PAE, and punt everything else or you'll go mad).

	The combinatorial pain of committing to more than that leads to a desire for seppuku:  I had to support multiple kernel versions each (and often multiple configurations per kernel) for Red Hat 7, 8, 9; RHEL 4 and 5, SuSE Enterprise 9, 10, 10.1, and 10.2, SuSE Desktop 9 and 10, and Fedora 4, 5, and 6 across x86, x86-64, and IA-64, and it ended up being more than 400 binaries to be generated, tested, and delivered every time we issued a patch release.

	Linux is shifting sand.  Picking and sticking to the default configurations of at most one major release each of two major distros, per FreeBSD release stream, at least puts you on the hard-packed stuff near the tide line.  Even that is a moving target, as RHEL and SuSE will issue a frequent stream of security updates that will bump kernel patch versions, so "version magic" gets to be a pain to get modules to auto-load, though there is some provision for "weak" symbol versioning in 2.6.18 and beyond.

-- 
Chris BeHanna
chris at behanna.org



More information about the freebsd-arch mailing list