Date: Mon, 3 Jan 2011 13:34:30 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: Garrett Cooper <gcooper@FreeBSD.org> Cc: arch@freebsd.org, Alfred Perlstein <alfred@freebsd.org> Subject: Re: Linux kernel compatability Message-ID: <alpine.BSF.2.00.1101031333400.1450@desktop> In-Reply-To: <AANLkTinUuQgqJ4AVHxE5ZtnuTO3SX1MNBDYYKSX_L=pK@mail.gmail.com> References: <alpine.BSF.2.00.1101031017110.1450@desktop> <20110103210223.GV2973@elvis.mu.org> <AANLkTinUuQgqJ4AVHxE5ZtnuTO3SX1MNBDYYKSX_L=pK@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2547152148-1943602431-1294097674=:1450 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT 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. Thanks, Jeff > Thanks, > -Garrett > --2547152148-1943602431-1294097674=:1450--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1101031333400.1450>