Linux kernel compatability

Warner Losh imp at bsdimp.com
Mon Jan 3 23:45:44 UTC 2011


On 01/03/2011 16:34, Jeff Roberson wrote:
> 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.

Yea, that's happened so often, one has to wonder if it is intentional on 
their part :)  But, alas, I think phk's signature actually explains it.

Warner


More information about the freebsd-arch mailing list