Linux kernel compatability

Max Khon fjoe at
Fri Jan 7 11:02:43 UTC 2011


On Tue, Jan 4, 2011 at 2:31 AM, Jeff Roberson <jroberson at>wrote:

Some of you may have seen my infiniband work proceed in svn.  It is coming
> to a close soon and I will be integrating it into current.  I have a few
> patches to the kernel to send for review but I wanted to bring up the KPI
> wrapper itself for discussion.
> The infiniband port has been done by creating a 10,000 line KPI
> compatability layer.  With this layer the vast majority of the driver code
> runs unmodified.  The exceptions are anything that interfaces with skbs and
> most of the code that deals with network interfaces.
> Some examples of things supported by the wrapper:
> atomics, types, bitops, byte order conversion, character devices, pci
> devices, dma, non-device files, idr tables, interrupts, ioremap, hashes,
> kobjects, radix trees, lists, modules, notifier blocks, rbtrees, rwlock,
> rwsem, semaphore, schedule, spinlocks, kalloc, wait queues, workqueues,
> timers, etc.
> Obviously a complete wrapper is impossible and I only implemented the
> features that I needed.  The build is accomplished by pointing the linux
> compatible code at sys/ofed/include/ which has a simulated linux kernel
> include tree.  There are some config(8) changes to help this along as well.
> 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?

DAHDI/FreeBSD project will surely benefit from having your linux KAPI compat
layer in the tree.

I even considered to use your KAPI compat layer but decided to stay with own
linux KAPI emulation layer (much thinner, but much less featured and
complete when compared to your work) because your work requires kernel
modifications (AFAIR there were changes at least in sleepqueue FreeBSD KAPI)
but I needed support for FreeBSD 7/8 without requiring end users to apply
kernel patches.

I will definitely use your KAPI compat layer once it is made available in
the tree. Also, it may have sense to have a backport for older FreeBSD
releases (or have it as a FreeBSD port) and to commit those kernel
modifications to earlier releases.

For those that think that linux KAPI compat may distract developers from
FreeBSD: Digium folks would not like to have OS-independent layer + Linux or
FreeBSD layers below it in their DAHDI source tree because they plan to have
their code merged into Linux mainline some time and it would be much harder
(if not completely impossible) to have it in mainline _with_ KAPI
abstraction layer.

So I did not have other choice than having linux KAPI compat layer in the


More information about the freebsd-arch mailing list