From owner-svn-src-head@FreeBSD.ORG Thu Jan 2 21:27:06 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DB498C3; Thu, 2 Jan 2014 21:27:06 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id B5ED914D9; Thu, 2 Jan 2014 21:27:04 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id CA17E47A; Thu, 2 Jan 2014 22:20:09 +0100 (CET) Date: Thu, 2 Jan 2014 22:27:58 +0100 From: Pawel Jakub Dawidek 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: <20140102212757.GA1672@garage.freebsd.pl> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20140102131308.GI59496@kib.kiev.ua> X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Stanislav Sedov , svn-src-head@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein , src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 21:27:06 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 02, 2014 at 03:13:08PM +0200, Konstantin Belousov wrote: > On Thu, Jan 02, 2014 at 11:49:04AM +0100, Pawel Jakub Dawidek wrote: > > I don't plan to provide alternative way to fetch the cap stuff. Well, I > > implemented libnv, which can be used to reimplement how we fetch all > > data like kinfo_file in a ABI friendly way, but I don't plan to modify > > this specific code myself. > I.e. you break something and decline to fix it, putting the burden on > somebody else. That's a bit too far. I wasn't declining fixing a bug I introduced. I was declining implementing an improvement. That's two very different things. Chose your words more carefully and not only this time. > > 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. [...] To address your statement that either entire ABI is stable or not and there is nothing in between. That's of course incorrect. First of all, we, as a project, don't consider all existing interfaces as stable. This would be a suicide. There are plenty of private interfaces we must and we do break from release to release. There was at least one case, AFAIR, where we broke ABI because of a security issue. I also think that breaking ABI on unused interfaces can be fine too. We don't support ABI compatibility with FreeBSD 1, no matter how close we are, and we had this discussion in the past. I'm also in opinion that even if one day we run out of spare fields in kinfo_* structures the FreeBSD project should not be terminated. Ok, let's be more constructive. I can use existing spare ints. This would move the problem into the future and will break ABI for existing 10-RCs. We can also investigate how huge breakage that is. The sysctl interface is not public API, so I don't believe we should be concerned by its direct consumers. We have two public interfaces for this: libutil's kinfo_getfile(3) which has exactly one in-base consumer - libprocstat, so this change breaks procstat(1) and fstat(1). > This is just awful breakage of _ABI_. We cannot leave it as is, > unless we also claim that project gave up on ABI stability at all. [...] > My own opinion is that the kinfo change must be removed, and the bug > is so critical that another RC must be issued. I personally don't consider it so awful and critical as you do, clearly, but I do recognize it as a problem. I'm happy to consume spares, which should fix compatibility with older releases at the cost of breaking compatibility with 10-RCs. At least for i386 and amd64, not sure how using ints for uint64_t will work for other archs. I'll leave it for re@ to decide. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlLF2d0ACgkQForvXbEpPzQ3MACffU+tglMuwUlYYXTCgOY8ZYRy tHoAn1ogw9rJLDgvfNDNJ5fgFqpjWhMZ =5Qhj -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv--