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