From owner-svn-src-all@FreeBSD.ORG Thu Jan 2 19:59:37 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 05E35166; Thu, 2 Jan 2014 19:59:37 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D88C1D1C; Thu, 2 Jan 2014 19:59:36 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s02JxZRj021329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jan 2014 11:59:36 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s02JxZg3021328; Thu, 2 Jan 2014 11:59:35 -0800 (PST) (envelope-from jmg) Date: Thu, 2 Jan 2014 11:59:35 -0800 From: John-Mark Gurney 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... Message-ID: <20140102195935.GC99167@funkthat.com> 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> <20140102192612.GM59496@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140102192612.GM59496@kib.kiev.ua> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 02 Jan 2014 11:59:36 -0800 (PST) Cc: src-committers@FreeBSD.org, Pawel Jakub Dawidek , svn-src-all@FreeBSD.org, Alfred Perlstein , Stanislav Sedov , svn-src-head@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:59:37 -0000 Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 21:26 +0200: > On Thu, Jan 02, 2014 at 11:14:20AM -0800, 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? > Policy did not changed. Breaking ABI was never allowed, except for the > kernel management interfaces. Later was only accepted due to tight > relation of the typical management facilities and internal kernel > structures, but this is considered a bug. Please do no use such absolutes, since the ABI has been allowed to break in the recent past, as I'm looking at a commit in 2005 that broke struct kproc_info size... > > I did a quick search for "freebsd policy abi breakage" and found some > > mailing list posts about this, but no authoritative statement... > Re tried to write down the policy, last time it was several years ago. > The efforts should be revived. > > > > > 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 do not understand what are you trying to say. My point is that once we move to the "new ABI", we will either have to accept that we stop maintaining the old interface, or we write and maintain the old interface, but if we do, what's the point of going to the new interface if the old interface "never" breaks? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."