Date: Mon, 03 Jan 2011 16:40:06 -0700 From: Warner Losh <imp@bsdimp.com> To: freebsd-arch@freebsd.org Subject: Re: Linux kernel compatability Message-ID: <4D225E56.2080603@bsdimp.com> In-Reply-To: <alpine.BSF.2.00.1101031333400.1450@desktop> References: <alpine.BSF.2.00.1101031017110.1450@desktop> <20110103210223.GV2973@elvis.mu.org> <AANLkTinUuQgqJ4AVHxE5ZtnuTO3SX1MNBDYYKSX_L=pK@mail.gmail.com> <alpine.BSF.2.00.1101031333400.1450@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> >> wrote: >>> * Jeff Roberson <jroberson@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D225E56.2080603>