Linux kernel compatability

Garrett Cooper gcooper at FreeBSD.org
Mon Jan 3 23:16:17 UTC 2011


On Mon, Jan 3, 2011 at 1:02 PM, Alfred Perlstein <alfred at freebsd.org> wrote:
> * Jeff Roberson <jroberson at jroberson.net> [110103 12:51] 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?
>
> I think this is really cool.  Brilliant actually.
>
> What do you think about proposing it on some standards list as a
> cross unix KPI?  That way we can see upcoming changes and maybe
> have a say in pushing back on gratuitous changes that would break
> our clients?

    That would be really nice, but I doubt people could agree on a
single set of KPIs for everything and given the rate of progress with
opengroup, I don't think it will fly (in particular with our and
Linux's rate of development). Thankfully some of stuff (from what I've
seen) is easy to port back and forth, but it varies depending on how
tied the code is to the OS of course :(.
Thanks,
-Garrett


More information about the freebsd-arch mailing list