From owner-svn-src-stable@FreeBSD.ORG Sun Dec 30 14:00:52 2012 Return-Path: Delivered-To: svn-src-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4FC51C9; Sun, 30 Dec 2012 14:00:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by mx1.freebsd.org (Postfix) with ESMTP id 6DA758FC13; Sun, 30 Dec 2012 14:00:52 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id un1so6630786pbc.20 for ; Sun, 30 Dec 2012 06:00:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=wSzllmYNABJlnOI5I+47NEXryQPMC1i8rTpGB2MFjmA=; b=XzqZHtwOhq2DfNp1p2vIGj4ELcFQ7iqqnRuxKt6lvY9mKiUPMX6Y78+gdCXv91KIgO y7Yvq5KXEYvDRBSbD65wNbpDHvgqP45U4LsgLI32memvxrAbY1wDT7zLQ565+QHrEUHY 0qlTBeIEhKgZuuZrOQSJd0D3p5Y+JsTMBRkgMzoBhF1pzTwO3lpeQc1q9trOofnx+Fix E+8XU6E1iPOiksUmLEfhom6f0RV01EeXPZJgKzwHSFU+7IHt8dh9kFkeqACWJWIqmaAa qBVi4omwMTaJL6IMmsz4ObqNRcps2m1koazqeOrApPOHEe7mq/uUGFFEWHQkuJPoxRPR pQyQ== X-Received: by 10.68.209.133 with SMTP id mm5mr120933289pbc.42.1356874628211; Sun, 30 Dec 2012 05:37:08 -0800 (PST) Received: from [192.168.20.12] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id v2sm23903256paz.36.2012.12.30.05.37.05 (version=SSLv3 cipher=OTHER); Sun, 30 Dec 2012 05:37:06 -0800 (PST) References: <201212241422.qBOEMrcF021632@svn.freebsd.org> <50D8B533.8080507@mu.org> <20121225104422.GB53644@kib.kiev.ua> <00E4FFFA-8ADB-4D43-B977-3834C48133E4@freebsd.org> <20121230103105.GH5028@garage.freebsd.pl> Mime-Version: 1.0 (1.0) In-Reply-To: <20121230103105.GH5028@garage.freebsd.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <25D528BC-8D25-4566-9B53-0BF2927ED1B2@gmail.com> X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: svn commit: r244663 - stable/9 Date: Sun, 30 Dec 2012 05:37:02 -0800 To: Pawel Jakub Dawidek Cc: Benjamin Kaduk , "mdf@FreeBSD.org" , "src-committers@freebsd.org" , "svn-src-stable@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-stable-9@freebsd.org" , "Robert N. M. Watson" X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 14:00:52 -0000 On Dec 30, 2012, at 2:31 AM, Pawel Jakub Dawidek wrote: > On Sat, Dec 29, 2012 at 08:43:56PM -0800, mdf@FreeBSD.org wrote: >> On Sat, Dec 29, 2012 at 6:38 PM, Benjamin Kaduk wrote= : >>> On Sat, Dec 29, 2012 at 5:44 AM, Robert N. M. Watson >>> wrote: >>>>=20 >>>> When we talked to various VFS maintainers, looked at the past change >>>> history there, and looked at the set of third-party file systems >>>> (especially, those we could see in ports), the consensus there was that= it >>>> was too difficult to define a stable VFS KPI and KBI for third-party >>>> modules. In particular, there appear to be at most one or two in ports a= t >>>> any given moment, and quick analyses of them suggested that their kerne= l >>>> feature dependency footprint was far more than just "vnode operations".= >>>=20 >>>=20 >>> If OpenAFS is the only out-of-tree filesystem in ports, then most defini= tely >>> there are far more dependencies in place. I don't know how closely Isil= on's >>> stuff keeps to our models >>=20 >> KBI/ABI are not relevant for Isilon since we build universe every >> time. Changes to the KPI need to be tracked, of course. >=20 > I agree that KBI is not that much important to vendors, it is better to > prepare build infrastructure that will compile everything and create > instalation image or upgrade package. KPI is of course totally different > story. >=20 >> I don't know if there are other vendors with a custom filesystem who >> are not shipping a whole system (NetApp has a pretty odd use case >> AFAIK). >=20 > There are other vendors, but from my experience vendors don't really > follow stable as close as possible. Once "good enough" stable/N revision > is found, vendors will stick to it, most likely until at least > stable/N+1 appears. Most of the time there are no changes significant > enough in stable branch to afford the slide and all the testing. This is > a lot of work and random things can break. Even if there are important > changes, they may also be cherry-picked instead of upgrading everything. > And if the next upgrade is done to stable/N+1, vendor will have to deal > with KPI changes anyway. It is very nice if KPI changes in a way that > code no longer compiles, so changing order of bcopy(9) arguments is not > welcome:) >=20 > To sum up, I think stable KPI/KBI is most important for 3rd-party kernel > modules. We don't want them to stop loading once user upgrades because of > security fix and if we can't avoid the breakage UPDATING entry is a > must. >=20 > I wonder how many 3rd-party kernel modules do we have in ports. If not > that many maybe we could provide new target to ports' Makefile to just > build kernel modules to verify they at least compile. This would help > catch problems like the recent one with VM KPI change and VirtualBox > modules easier. open-vm-tools, virtualbox-ose-kmod, fusefs-kmod, and kqemu-kmod* are the big= pain points I discovered because they generally delve in low-level kpis lik= e vfs, vm, and newbus. > As for the KBI, maybe installkernel could verify that modules in > ${DESTDIR}/boot/modules/ are compiled for the same __FreeBSD_version and > warn if not? That would be somewhat interesting, but fixing everything to work with PORTS= _MODULES to ensure that one's kernel and ports klds are in synch should be t= he well defined/supported model, s.t. having to focus on this becomes a non-= issue. Thanks, -Garrett