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