Linux kernel compatability

Jeff Roberson jroberson at jroberson.net
Tue Jan 4 05:00:23 UTC 2011


On Mon, 3 Jan 2011, Alexander Kabaev wrote:

> On Mon, 3 Jan 2011 10:31:24 -1000 (HST)
> Jeff Roberson <jroberson at jroberson.net> wrote:
>
>> Hello Folks,
>>
>> 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?
>>
>> Other comments or concerns?
>>
>> Thanks,
>> Jeff
>
>
> This probably will go against popular opinion here, but having 10k
> linux emulation layer that _almost_ work in the tree will be an
> unfortunate event and will do more damage to FreeBSD as a platform than
> good in the long run. I would rather see this code never hit main
> repository.

I would argue that the layer works very well for infiniband.  Much better 
than almost.  It is only almost complete in that there is no need for me 
to implement features that we're not using.

I am interested in hearing your other concerns however.

Thanks,
Jeff

>
> -- 
> Alexander Kabaev
>


More information about the freebsd-arch mailing list