From owner-freebsd-fs@FreeBSD.ORG Sat Jul 21 19:08:35 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 465E51065670 for ; Sat, 21 Jul 2012 19:08:35 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7F98FC1D for ; Sat, 21 Jul 2012 19:08:35 +0000 (UTC) Received: from [192.168.135.103] (c-76-126-166-136.hsd1.ca.comcast.net [76.126.166.136]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id q6LJ8Scn075633 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 21 Jul 2012 12:08:29 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <500AFE27.9000700@feral.com> Date: Sat, 21 Jul 2012 12:08:23 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20120721185547.GD2676@deviant.kiev.zoral.com.ua> In-Reply-To: <20120721185547.GD2676@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Sat, 21 Jul 2012 12:08:29 -0700 (PDT) Subject: Re: KBI bump in r227697? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matt Jacob List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 19:08:35 -0000 > This is r229703 for stable/9. > The __FreeBSD_version was already bumped after that change, at least 3 times. > In fact, the bump to 900501 in r229723 is almost immediately after it. > > For HEAD, it makes no sense to bump the revision at all, since you are > assumed to always run latest HEAD. Really? This puzzles me. You're not really supposed to make KBI changes in stable- otherwise stable isn't a stable place for vendor KOBJs. When you make KBI changes, independent of whether head or not, a revision bump is useful so that dependent code knows when it has to change. This change carries forward and backwards for compilation independent of which branch this is in.