From owner-freebsd-arch@FreeBSD.ORG Fri Jan 7 15:15:22 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 804FE106566B for ; Fri, 7 Jan 2011 15:15:22 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2EC138FC18 for ; Fri, 7 Jan 2011 15:15:22 +0000 (UTC) Received: from grapeape2.cs.duke.edu (grapeape2.cs.duke.edu [152.3.140.76]) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id p07FFLVT013298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jan 2011 10:15:21 -0500 (EST) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu p07FFLVT013298 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1294413321; bh=+7pms0GeDu0RNQW6KoUAH+QDTkZ5XC9Wz4J7PMn8p0Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=nIZuBIhvhjvPmsqxPBMhY+nN6k4xcXjfezEIoiN4lUdjRQ6Ux0OBG4ni37TuzrT9M beirLh5xK2OdPwSxvnA7xZUIfqua1g/uKibnFm7lscl6w9svM/eWMuv3H7GBpyx5vN WGX9rdoMp7ggcSNbhK10lnVfM38HOzhMQ1LyrP/VPbxqEk/jojtwAOJJ3Yyj0G3oBU Aucsp8DaRpQblfd2IQo5mSVwVwlZT/BJIrlSnzRULO8orcIOASYgR3Vcx8R5FR99kZ 83ST7nf8wsNA8ABL7llBgOeRhdGFEBRU86bjTcUFMLk+9iApPju6mVjhYkZVT/ghL3 M6UdKZFUatupA== Received: (from gallatin@localhost) by grapeape2.cs.duke.edu (8.12.10/8.12.10/Submit) id p07FFKam010007; Fri, 7 Jan 2011 10:15:20 -0500 (EST) Date: Fri, 7 Jan 2011 10:15:20 -0500 From: Andrew Gallatin To: Jeff Roberson Message-ID: <20110107151520.GA9925@grapeape2.cs.duke.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: SunOS 5.10 on an sun4u User-Agent: Mutt/1.5.13 (2006-08-11) 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 15:15:22 -0000 This looks fantastic! Jeff Roberson [jroberson@jroberson.net] wrote: > 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? I'd prefer to see it in a central place so that other projects could add to the interfaces. For example, I've long wanted to get the V4L DVB tree compiling on FreeBSD, but I've never had the time to start the project. I imagine it has just gotten 90% easier. > Other comments or concerns? What version of the linux kernel do you target? I've just been browsing the SVN repo, but I did not see a linux/version.h with a #define LINUX_VERSION_CODE in it. That suggests there is no chance of getting "simple", single file character drivers with build instructions like make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd` to work. I guess there a more complex glue layer for building? For people complaining about linux API churn -- there is a stable linux KABI via RHEL. Each major RHEL release has a symbol whitelist that they promise to maintain binary compat for across the lifetime of the major release (many years). I honestly think the "holy grail" would be to implement enough of the RHEL6 KABI that you could just load binary linux drivers built on RHEL6 the same way we load NDIS drivers. BTW, is OFED KABI compliant on RHEL? Eg, can you build an OFED DUT that will work across RHEL revisions, or is it tied to symbols that are not on the kabi whitelist? At work, I maintain our linux driver (and FreeBSD & all *nix drivers). For a "simple" 10G NIC, we're at about 1K LOC for shims to allow us to compile on later 2.4 and all 2.6 kernels. So I'm impressed at "just" 10K LOC for a shim layer between FreeBSD & Linux. ESX uses slightly modified linux drivers via a shim layer. So there is a precedent for this & they are a much fatter GPL target. FWIW, I've often wished for a native ESX interface, since their shim layer is "not quite" linux, and takes features from different versions. I don't see us dropping native FreeBSD support even if the shim layer was as good as ESX's. Drew