From owner-freebsd-arch@FreeBSD.ORG Mon Jan 3 23:45:44 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 055E91065670 for ; Mon, 3 Jan 2011 23:45:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id ABD3D8FC16 for ; Mon, 3 Jan 2011 23:45:43 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p03Ne8AU066645 for ; Mon, 3 Jan 2011 16:40:08 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D225E56.2080603@bsdimp.com> Date: Mon, 03 Jan 2011 16:40:06 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <20110103210223.GV2973@elvis.mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Linux kernel compatability X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 23:45:44 -0000 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 >> wrote: >>> * Jeff Roberson [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