From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 16:05:33 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 E779D106564A for ; Tue, 4 Jan 2011 16:05:33 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id A9FFE8FC1A for ; Tue, 4 Jan 2011 16:05:33 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 9DF5558143; Tue, 4 Jan 2011 09:37:24 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id zMWJvM3FXatO; Tue, 4 Jan 2011 09:37:24 -0600 (CST) Received: from wanderer.tachypleus.net (unknown [76.210.75.5]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 108CD5811E; Tue, 4 Jan 2011 09:37:23 -0600 (CST) Message-ID: <4D233EB3.100@freebsd.org> Date: Tue, 04 Jan 2011 09:37:23 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101227 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alexander Kabaev References: <20110103220153.69cf59e0@kan.dnsalias.net> <20110104082252.45bb5e7f@kan.dnsalias.net> In-Reply-To: <20110104082252.45bb5e7f@kan.dnsalias.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 04 Jan 2011 16:05:34 -0000 On 01/04/11 07:22, Alexander Kabaev wrote: > On Mon, 3 Jan 2011 19:03:01 -1000 (HST) > Jeff Roberson wrote: > >> On Mon, 3 Jan 2011, Alexander Kabaev wrote: >> >>> On Mon, 3 Jan 2011 10:31:24 -1000 (HST) >>> Jeff Roberson wrote: >> I would argue that the layer works very well for infiniband. Much >> better than almost. It is only almost complete in that there is no >> need for me to implement features that we're not using. >> >> I am interested in hearing your other concerns however. >> >> Thanks, >> Jeff >> > > The considerations are simple enough. First, we do not have many IB > users of FreeBSD in the wild and those that we have (Isilon) seem to be > perfectly capable of managing the IB stack out of the tree, without > dumping the thousands of lines of the code into the base. If they had > the stack before, but were not willing/capable to provide adequate care > for it in the past, there is no reason to expect things to change with > second stack, which now will rot in our tree instead of theirs. Before this, it was very difficult to be an Infiniband user on FreeBSD, which I think explains the dearth. And that Isilon chose to port this giant piece of code twice indicates that they do care very much. > Second, semi-complete Linux compat layer in kernel will have the > same effect as linuxulator in userland - we do have some vendors still > trying to bother with FreeBSD drivers for their hardware now and we > will have none after we provide the possibility to hack their Linux > code to run somewhat stably on top of Linux compat layer. Due to > intentional fluidity of Linux kAPI, our shims will never quite walk and > quack like their original implementation in Linux kernel and combined > result will always be lees stable than native Linux linux drivers in > Linux kernel. This is perhaps an argument for keeping it tightly coupled to the Infiniband stack, but certainly not for keeping it out of the tree. It seems that most vendor drivers have their own adaptation layer anyway and it would be just as easy for them to continue supporting FreeBSD as they always have. Project Evil did not lead to a huge decrease in availability of FreeBSD network drivers. As far as I understand, as well, this emulation layer is much less complete even than our NDIS support. -Nathan