Linux kernel compatability

[Jeff Roberson]

On Mon, 3 Jan 2011, Garrett Cooper wrote:

> 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 :(.

Also, linux likes to change things very rapidly.  Not to mention a lot of 
their APIs go against the grain on BSD and we would not find them 
aesthetically or architecturally pleasing.

Thanks,
Jeff

> Thanks,
> -Garrett
>