From owner-freebsd-arch@FreeBSD.ORG Mon Jan 3 20:50:37 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 3AAF1106566C for ; Mon, 3 Jan 2011 20:50:37 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D16348FC0C for ; Mon, 3 Jan 2011 20:50:36 +0000 (UTC) Received: by wyf19 with SMTP id 19so13694620wyf.13 for ; Mon, 03 Jan 2011 12:50:36 -0800 (PST) Received: by 10.216.0.140 with SMTP id 12mr8054734web.29.1294086523318; Mon, 03 Jan 2011 12:28:43 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id 7sm10094615wet.24.2011.01.03.12.28.41 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 12:28:42 -0800 (PST) Date: Mon, 3 Jan 2011 10:31:24 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: arch@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: 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 20:50:37 -0000 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? Thanks, Jeff