From owner-freebsd-arch@FreeBSD.ORG Fri Jan 7 11:02:43 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 140C4106564A for ; Fri, 7 Jan 2011 11:02:43 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id C05DD8FC18 for ; Fri, 7 Jan 2011 11:02:42 +0000 (UTC) Received: by qwj9 with SMTP id 9so17007701qwj.13 for ; Fri, 07 Jan 2011 03:02:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.220.133 with SMTP id hy5mr21839293qcb.269.1294396564460; Fri, 07 Jan 2011 02:36:04 -0800 (PST) Received: by 10.229.233.209 with HTTP; Fri, 7 Jan 2011 02:36:04 -0800 (PST) X-Originating-IP: [109.174.58.22] In-Reply-To: References: Date: Fri, 7 Jan 2011 16:36:04 +0600 Message-ID: From: Max Khon To: Jeff Roberson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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: Fri, 07 Jan 2011 11:02:43 -0000 Jeff, On Tue, Jan 4, 2011 at 2:31 AM, Jeff Roberson wrote: 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? > DAHDI/FreeBSD project will surely benefit from having your linux KAPI compat layer in the tree. I even considered to use your KAPI compat layer but decided to stay with own linux KAPI emulation layer (much thinner, but much less featured and complete when compared to your work) because your work requires kernel modifications (AFAIR there were changes at least in sleepqueue FreeBSD KAPI) but I needed support for FreeBSD 7/8 without requiring end users to apply kernel patches. I will definitely use your KAPI compat layer once it is made available in the tree. Also, it may have sense to have a backport for older FreeBSD releases (or have it as a FreeBSD port) and to commit those kernel modifications to earlier releases. For those that think that linux KAPI compat may distract developers from FreeBSD: Digium folks would not like to have OS-independent layer + Linux or FreeBSD layers below it in their DAHDI source tree because they plan to have their code merged into Linux mainline some time and it would be much harder (if not completely impossible) to have it in mainline _with_ KAPI abstraction layer. So I did not have other choice than having linux KAPI compat layer in the end. Max