From owner-svn-src-all@FreeBSD.ORG Fri Jan 3 05:55:09 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 ECC81D4A; Fri, 3 Jan 2014 05:55:09 +0000 (UTC) Received: from mx0.deglitch.com (unknown [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9774F1A1D; Fri, 3 Jan 2014 05:55:09 +0000 (UTC) Received: from [192.168.1.61] (unknown [37.113.188.80]) by mx0.deglitch.com (Postfix) with ESMTPSA id A9EB78FC40; Fri, 3 Jan 2014 09:54:59 +0400 (MSK) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) 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... From: Stanislav Sedov In-Reply-To: <20140102212757.GA1672@garage.freebsd.pl> Date: Thu, 2 Jan 2014 21:54:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <99767738-1AEB-481F-8096-DC3D914F80B0@freebsd.org> 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> <20140102212757.GA1672@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1827) Cc: Konstantin Belousov , svn-src-head@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein , src-committers@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: Fri, 03 Jan 2014 05:55:10 -0000 On Jan 2, 2014, at 1:27 PM, Pawel Jakub Dawidek wrote: > 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 arches. Personally, I=92d prefer if we use spare fields for now. That will = allow us to maintain ABI stability for the current release, and have enough = time to implement the new, incompatible, interface in addition to the old one in HEAD. The interface is used a lot by 3rd party applications to = obtain the information about open file descriptors (in place of the Linux=92 = /proc interface), and this change will leave 9.x and before binaries broken in a subtle way on 10.x and beyond. Most of the commercial applications = are shipped compiled against 9.x or even 8.x and 7.x, and although the = extent of the damage is unknown, it might turn out to be a problem. To me, it seems that breaking the ABI with 10.x RC is less dangerous. -- ST4096-RIPE