From owner-svn-src-all@FreeBSD.ORG Thu Jan 2 19:45:33 2014 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 656F159D; Thu, 2 Jan 2014 19:45:33 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 48B2A1AFA; Thu, 2 Jan 2014 19:45:32 +0000 (UTC) Received: from Alfreds-MacBook-Pro.local (50-204-88-5-static.hfc.comcastbusiness.net [50.204.88.5]) by elvis.mu.org (Postfix) with ESMTPSA id 2F4D21A3C37; Thu, 2 Jan 2014 11:45:32 -0800 (PST) Message-ID: <52C5C1DB.8030308@mu.org> Date: Thu, 02 Jan 2014 11:45:31 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensola... References: <201309050009.r8509vsE061271@svn.freebsd.org> <67DFFD7B-01DE-4862-BED3-DD42EB92A8F4@freebsd.org> <20140102093322.GA1655@garage.freebsd.pl> <52C53F69.3040507@mu.org> <20140102104904.GB1655@garage.freebsd.pl> <20140102131308.GI59496@kib.kiev.ua> <20140102191420.GB99167@funkthat.com> <52C5BCCB.6070702@mu.org> <20140102193413.GN59496@kib.kiev.ua> In-Reply-To: <20140102193413.GN59496@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, Pawel Jakub Dawidek , John-Mark Gurney , Stanislav Sedov , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 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: Thu, 02 Jan 2014 19:45:33 -0000 On 1/2/14, 11:34 AM, Konstantin Belousov wrote: > On Thu, Jan 02, 2014 at 11:23:55AM -0800, Alfred Perlstein wrote: >> On 1/2/14, 11:14 AM, John-Mark Gurney wrote: >>> Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 15:13 +0200: >>>>>> Afaik you could just remove the "spare" and steal 2 or 4 entries from >>>>>> _kf_ispare until it is sorted. >>>>> Yes, this would work for current cap_rights_t structure, at least for >>>>> i386 and amd64, but would only allow to expand the structure by one >>>>> uint64_t in the future (which might or might not be enough). The >>>>> cap_rights_t structure is designed to be expanded to 5 uint64_ts without >>>>> breaking ABI. I don't want to stuck with current cap_rights_t that is >>>>> designed to expand, but cannot be, because kinfo_file wasn't modified at >>>>> the start of a major branch. >>>> The ABI stability is not limited to the single branch. It must be >>>> preserved across whole project lifetime. >>> Umm. when did this policy change happen? I thought ABI compatibility >>> was limited to major releases of FreeBSD? How are you suppose to do >>> any work if you can't break ABI ever? >>> >>> I did a quick search for "freebsd policy abi breakage" and found some >>> mailing list posts about this, but no authoritative statement... >>> >>> Of course the problem is that when we move to >>> (ASN.1/libnv/ctf/YAML/JSON/XML/etc) we will break ABI compatibility too, >>> or introduce tons of compatibility code that will rot... >>> >> I agree, however there is a very easy way to fix it for the time being. >> Let's not be binary about it "well it's going to have to break, so let's >> break it!" when such an easy way to not break it exists. It should be >> "let's see if there's a non-intrusive way of not breaking it" and the >> answer to that seems to be "yes". > If parts of ABI is broken, then why spend efforts trying to keep other > parts stable ? You already have random set of binaries broken, sometimes > in subtle way. Then, making other interfaces stable is just a waste. > > ABI stability is a yes/no proposition, you cannot have it partly done. > Personally, I do not want to spend a time on hobbyist system. > > BTW, to point out obvious thing, Linux has almost perfect ABI stability > and forward compatibility. It is pity to see that our people do not > understand the importance and benefits of it. I agree strongly. -Alfred