From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 18:18:54 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 E31651065696 for ; Tue, 4 Jan 2011 18:18:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BDB0F8FC18 for ; Tue, 4 Jan 2011 18:18:54 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5B97846B09; Tue, 4 Jan 2011 13:18:54 -0500 (EST) Date: Tue, 4 Jan 2011 18:18:54 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jeff Roberson In-Reply-To: Message-ID: References: <82826.1294088199@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Poul-Henning Kamp 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 18:18:55 -0000 On Mon, 3 Jan 2011, Jeff Roberson wrote: >> Those where there are substantial differences, we should only have one >> compat layer, not one for each driver. > > I would like this to be the case. So we can converge on something complete. > There are of course big differences between minor linux kernel revisions and > that poses problems. However those should be easier than the bsd/linux > differences. > > I think my proposal is to move these files to a more generic location so > they are more visible and available to other projects. Maintainers of > individual kernel ports would have to decide if they want to use what is > there. I think it's worth making a comparison with how we handle our Open Solaris shim parts, found (largely) in opensolaris.ko, which supports Solaris-derived features such as DTrace and ZFS. It is forced to address header location issues, license isolation issues, etc, and there may be some useful lessons there. There are also some potentially relevant problems: for example, in a formal sense, what version of an OS's KPI do we track? I'm no expert on opensolaris.ko, but my recollection is that we had a problem for a while where our versions of DTrace and ZFS did not come from the same version of Solaris. This even though the Sun (now Oracle) folks put a lot of work into stable kernel programming interfaces for dervice driver authors, etc. The Linux community is less well-known for its efforts in this area, and have faster-moving KPIs. Do we think there's sufficient KPI stability there to have a linux_kpi.ko (or whatever) that can serve more than one major consumer? Or is it sufficient to say that all Linux-derived code should track one Linux kernel version? On a related note, I've been pondering Apple's KPI changes to FReeBSD recently as well -- I'd like to import some of their many enhancements to our smbfs (also to be found in Solaris, FYI), and their KPI work has minimised easy porting of changes between the FreeBSD and Mac OS X. Since we invest relatively little work in smbfs, and they are deeply invested in a functional smbfs, I've also been pondering an xnu.ko (or at least, xnu_mbuf.h). Finally, lest we convince ourselves that every KPI is better/worse than ours: the same problem exists for people working on several other OS's that downstream our code: Mac OS X, Solaris, NetBSD, OpenBSD, etc. Operating system kernels are rapidly evolving, highly concurrent, highly specialised, and highly optimised C programs -- not only is variation a pretty natural thing, but I suspect any attempt to standardise would hold everyone back. Robert