From owner-svn-src-stable@FreeBSD.ORG Sun Dec 30 13:32:36 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 AD97AB42; Sun, 30 Dec 2012 13:32:36 +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 640388FC0A; Sun, 30 Dec 2012 13:32:36 +0000 (UTC) Received: from [192.168.2.119] (host86-129-88-139.range86-129.btcentralplus.com [86.129.88.139]) by cyrus.watson.org (Postfix) with ESMTPSA id C1C7646B3C; Sun, 30 Dec 2012 08:32:28 -0500 (EST) Subject: Re: svn commit: r244663 - stable/9 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: "Robert N. M. Watson" In-Reply-To: Date: Sun, 30 Dec 2012 13:32:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201212241422.qBOEMrcF021632@svn.freebsd.org> <50D8B533.8080507@mu.org> <20121225104422.GB53644@kib.kiev.ua> <00E4FFFA-8ADB-4D43-B977-3834C48133E4@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1283) Cc: src-committers@freebsd.org, svn-src-stable@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein , svn-src-stable-9@freebsd.org, Konstantin Belousov 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 13:32:36 -0000 On 29 Dec 2012, at 14:50, Adrian Chadd wrote: >> The standing consensus is that we try not to break certain classes of = device drivers, not that we don't ever change any kernel interfaces. The = reason is that we don't have a formal definition of "public" and do not = wish to use the definition "all definitions in all header files" or "all = symbols ever linked by any module" -- that definition would prevent = almost any change to the kernel in -STABLE branches at all. The reason = VIMAGE/MRT/etc had to be done with great caution is that they directly = affected network device drivers, which are a category of module which we = have decided we do want to try to support in external binary form. The = other major category is binary storage drivers. >>=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 = at any given moment, and quick analyses of them suggested that their = kernel feature dependency footprint was far more than just "vnode = operations". >>=20 >> KPIs and KBIs have benefits and downsides: we need to consider them = as a tradeoff space, and not an absolute, and use them where they have = significant payoff. Especially as we don't have formal tools for = reasoning about or testing them. >=20 > Sure, that's a logical, reasoned analysis of what the state of play of > the VFS interface and users. But again, it'd have been nice to get > some notification before it was pushed to -stable, just as a heads up > (and a chance for feedback) for people and companies who aren't on > your radar. Unless a module is in one of the narrow class of {network, storage} = device drivers, then third parties should expect to always recompile any = locally compiled modules, and always perform an analysis of whether = local kernel extensions are affected by upstream changes. Remember that the interfaces for "file systems" aren't just the vnode = interface -- it's also interfaces to VM, the buffer cache, the network = stack, in-kernel and file system-related locking, quotas, ACLs, IPC, = etc. A key reason why we are moving FUSE into the tree is to provide = easier access to file system extensions without having them depend on = kernel-internal interfaces. We provide a detailed change log for the kernel via Subversion and its = associated mailing lists, and that's the best (only) reference for = granular changes to our tens of thousands of kernel-internal interfaces. Robert=