From owner-svn-src-all@FreeBSD.ORG Sat Dec 29 06:40:18 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A244ADA1; Sat, 29 Dec 2012 06:40:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by mx1.freebsd.org (Postfix) with ESMTP id 72B628FC14; Sat, 29 Dec 2012 06:40:16 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id dt10so4957560wgb.15 for ; Fri, 28 Dec 2012 22:40:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kZk/x1aY5zUbRqApY5SjG26vmxQPRYVLGTYf3RuR5Zg=; b=TNA7uqvmPM3v3s+qVNmq/QeL4FIFu8N+gepf0atRchWClGBnrZT35023yfId9d7VC0 CcMj0uH4aSeHBKNpwN1k+J2WmgHVQKpO/ZcY5bjV/vvN6ZdErdVJe1pZfcIhSaunS76B XaOl6D3BHn83v46GH8UCuLqVIOv8kKx8uEHFpnnniyqaB5J5kfN7+KB7Qrh9jI0G+CcZ p5LxDna/ucTw+ZfAqCA5h42lnMprRFzJw/+l+H0UH2GvZ2xg9kcfLi6pwSSaLQIveqof ELSxD9wZ0vkmH5cZ1y8OmPEJg+5Xpq9uJ/OQO2sdYBsk9VrwTijzPYgLZfymNwN/ysPn afBA== MIME-Version: 1.0 Received: by 10.180.88.40 with SMTP id bd8mr47040166wib.33.1356763210341; Fri, 28 Dec 2012 22:40:10 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 28 Dec 2012 22:40:10 -0800 (PST) In-Reply-To: References: <201212241422.qBOEMrcF021632@svn.freebsd.org> <50D8B533.8080507@mu.org> <20121225104422.GB53644@kib.kiev.ua> Date: Fri, 28 Dec 2012 22:40:10 -0800 X-Google-Sender-Auth: 0YgNeKrEXfnDH1Ss_HenueyU3x4 Message-ID: Subject: Re: svn commit: r244663 - stable/9 From: Adrian Chadd To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 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-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 06:40:18 -0000 On 25 December 2012 11:17, Robert Watson wrote: > While I would love to have a stable KBI, or even KPI, for VFS, past > experience suggests that we are not prepared to document one, let alone > enforce it, and that we frequently experience changes that disrupt both the > binary and programming interfaces -- often for very good reasons (e.g., > fixing critical bugs, improving performance, etc). And that the notional > VFS KPI is extremely promiscuous, being made up of not just the obvious VFS > parts, but also VM parts, etc. We've done a bit better with device drivers, > where the consensus is that we should Try Fairly Hard, but even there we > have only limited documentation of what even constitutes the KPI and KBI. > In the end, not all kernel interfaces can be "KPIs" or "KBIs" -- otherwise, > we could change almost nothing in -STABLE, causing branches to stagnate > rapidly. If you look at Apple's model (for example), they designate certain > interfaces as "API" or "KPI" rather than using the terms more casually to > refer to any interface in userspace or kernel, and we need to take the same > perspective. A few years ago, I took a gander through a number of core > network stack data structures used by device drivers, while trying to help > resolve how TOE would fit into the network device driver picture, and you > can see the results here: There's likely a bunch of companies/users that would love things to not change during a stable branch and there's likely a bunch of companies/users that would hate things being immutable during a stable branch. There's never been a formal "kernel ABI stuff in stable shouldn't break" or not, but as far as I was aware, the unofficial method was "discuss on -stable or -arch to see whether it's worth the break, then break it if needed, or not-break it and add a dirty hack for that branch" if not. This is why things like vimage/vnet were so dirty in the backports, if you remember. Julian and others made a specific attempt _not_ to break KBI when backporting the feature. So, regardless of whether we should or shouldn't break things, a more thorough discussion would've been nice. Adrian