From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 01:54: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 ACE14106564A for ; Tue, 4 Jan 2011 01:54:44 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5182F8FC08 for ; Tue, 4 Jan 2011 01:54:43 +0000 (UTC) Received: from [172.16.135.102] (lportal.in1.lcl [172.16.1.9]) by ns1.feral.com (8.14.4/8.14.3) with ESMTP id p041LaiK000554 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 3 Jan 2011 17:21:37 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4D22761D.2020706@feral.com> Date: Mon, 03 Jan 2011 17:21:33 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <20110103210223.GV2973@elvis.mu.org> <4D225E56.2080603@bsdimp.com> In-Reply-To: <4D225E56.2080603@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Mon, 03 Jan 2011 17:21:37 -0800 (PST) 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 01:54:44 -0000 >> 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. > > You should read http://www.kernel.org/doc/Documentation/stable_api_nonsense.txt for a reasoning. It's also a misreading of both motive and capabilities to ascribe either malice or incompetence to the linux folks. On the title subject, having written several multiplatform drivers and been involved trying to write APIs and ABIs common to multiple platforms and OS' for the last 20 odd years or so, I have to say I have very mixed feelings about the approach Jeff has taken here. Syntactic differences between different OS functions are *generally* trivial. printf is printf. Semantic, and implied semantic differences can be tricky. The linux locking model is fundamentally different from the FreeBSD, and only conscious and careful programming in code that calls shim layer stuff can avoid problems (although maybe Jeff has been cleverer than I can be with this). Given the above, centralized KAPI services that multiple OS platforms can share seem a hard goal to reach. There was at least one (sponsored by SCO) which was a complete non-starter (despite the best of intentions). There have been several hardware based efforts that have also come a cropper (I20 and OBIOS). Even *within* a single OS community, variants abound that are irreconcilable (the multiple *BSDs; AT&T vs BSD; .....). And once you get outside the kernel, it's complete chaos (the multitude of Linux distros). I take from all of this that only select and relatively contained kernel subsystems are good candidates for multiple platform instantiations. Direct hardware drivers are generally pretty good for this since they can usually be written with shim type supports pretty easily. Filesystems are tricky. The attempts by SGI to maintain multiple platform versions of XFS have failed spectacularly. The GFS folks gave up on this one early. OFED is something of a special case. It's a very large body of code, written specifically for Linux, and is essentially the de facto standard for HPC interconnects. Like I said, I have mixed feelings about Jeff's approach here. On the one hand, that's a huge shim layer to write (10K LOC!). On the *other* hand, it makes importation of updated (Linux based) code quite workable. What that *does* imply is that native OFED development will unlikely ever be undertaken on FreeBSD (probably fine- whoza gonna pay for it that ain't paying for Linux development already?). The other thing to ask in making for common functionality is whether or not there are performance and/or functionality tradeoffs being made. There are things you can do in the FreeBSD kernel that you can't (easily) do in Linux (and vice versa). That's another consideration. Anyway, to end this meandering email, my suggestion would be "Yes, the 10K LOC would be useful for all modules to use!", but only expect it to work (well) for OFED.