Linux kernel compatability

Robert Watson rwatson at FreeBSD.org
Tue Jan 4 18:18:55 UTC 2011


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?

On a related note, I've been pondering Apple's KPI changes to FReeBSD recently 
as well -- I'd like to import some of their many enhancements to our smbfs 
(also to be found in Solaris, FYI), and their KPI work has minimised easy 
porting of changes between the FreeBSD and Mac OS X.  Since we invest 
relatively little work in smbfs, and they are deeply invested in a functional 
smbfs, I've also been pondering an xnu.ko (or at least, xnu_mbuf.h).

Finally, lest we convince ourselves that every KPI is better/worse than ours: 
the same problem exists for people working on several other OS's that 
downstream our code: Mac OS X, Solaris, NetBSD, OpenBSD, etc.  Operating 
system kernels are rapidly evolving, highly concurrent, highly specialised, 
and highly optimised C programs -- not only is variation a pretty natural 
thing, but I suspect any attempt to standardise would hold everyone back.

Robert


More information about the freebsd-arch mailing list