From owner-freebsd-arch@FreeBSD.ORG Mon Jan 3 21:18:42 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51933106564A for ; Mon, 3 Jan 2011 21:18:42 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 307378FC14 for ; Mon, 3 Jan 2011 21:18:41 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 223EE1A3C3A; Mon, 3 Jan 2011 13:02:24 -0800 (PST) Date: Mon, 3 Jan 2011 13:02:23 -0800 From: Alfred Perlstein To: Jeff Roberson Message-ID: <20110103210223.GV2973@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org 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 21:18:42 -0000 * 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? -Alfred