From owner-svn-src-all@FreeBSD.ORG Thu Jan 2 21:18:41 2014 Return-Path: Delivered-To: svn-src-all@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 2625B528; Thu, 2 Jan 2014 21:18:41 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D4EAE1410; Thu, 2 Jan 2014 21:18:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E6965B987; Thu, 2 Jan 2014 16:18:39 -0500 (EST) From: John Baldwin To: "John-Mark Gurney" 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... Date: Thu, 2 Jan 2014 16:18:22 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201309050009.r8509vsE061271@svn.freebsd.org> <20140102192612.GM59496@kib.kiev.ua> <20140102195935.GC99167@funkthat.com> In-Reply-To: <20140102195935.GC99167@funkthat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401021618.23155.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 02 Jan 2014 16:18:40 -0500 (EST) Cc: src-committers@freebsd.org, Pawel Jakub Dawidek , svn-src-all@freebsd.org, Alfred Perlstein , Stanislav Sedov , svn-src-head@freebsd.org, Konstantin Belousov 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 21:18:41 -0000 On Thursday, January 02, 2014 2:59:35 pm John-Mark Gurney wrote: > 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? *cough* Ahem. We've changed the ABI of kinfo_file once before already and supported both just fine. Please search for COMPAT_FREEBSD7 in kern_descrip.c. In this case this works because the relevant sysctls use fixed nodes, so you can add a new ABI by moving the names to the new numbers but leaving the old nodes in place for the old ABI. Shouldn't take a huge amount of work for Pawel to bang out appropriate COMPAT_FREEBSD8 | COMPAT_FREEBSD9 diffs for this. OTOH, this breaks the ABI for existing 10.x binaries, so it needs to be done ASAP. I don't know if any ports use these sysctls directly (psutil might). If so a recompile should generally "fix" them to move them to the new ABI once it is in place. (And yes, Pawel, since you are changing kinfo_file, this is your responsibility to fix.) -- John Baldwin