From owner-cvs-all@FreeBSD.ORG Tue Aug 28 02:46:29 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96A2F16A46B; Tue, 28 Aug 2007 02:46:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 264DE13C4A5; Tue, 28 Aug 2007 02:46:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l7S2kDne007322; Mon, 27 Aug 2007 20:46:13 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 27 Aug 2007 20:46:18 -0600 (MDT) Message-Id: <20070827.204618.-1350500405.imp@bsdimp.com> To: deischen@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <20070828004842.GT21352@comp.chem.msu.su> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 27 Aug 2007 20:46:13 -0600 (MDT) Cc: src-committers@freebsd.org, jhb@freebsd.org, yar@comp.chem.msu.su, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 02:46:29 -0000 In message: Daniel Eischen writes: : On Tue, 28 Aug 2007, Yar Tikhiy wrote: : > : > Example: Assume we released 7.0-R with all symbols at FBSD_1.0. : > Before the 8.0 release cycle starts, struct FTS and struct FILE : > change, perhaps a few times each, thus affecting the fts(3) and : > stdio(3) global symbols. At the very first change to a symbol or : > their group, its 7.0-R variant is preserved at FBSD_1.0 and its : > default version becomes FBSD_1.1. Later changes to the current : > variant of that symbol don't affect its version. Consequently, : > 8.0-R is released with the new fts(3) and stdio(3) symbols at : > FBSD_1.1, their 7.0-R variants at FBSD_1.0, and the rest of symbols : > still at FBSD_1.0 because they are unchanged. Let's note that : > CURRENT users had to rebuild ports depending on fts(3) or stdio(3) : > _each time_ an ABI component changed. : : I think you're a little confused here. CURRENT users did NOT have : to rebuild ports when fts(3) or stdio(3) ABIs changed. They : would only have to rebuild if one of these ABIs changed _more : than once between releases_. That hasn't ever happened to my : knowledge in the past, and it really shouldn't happen as long : as things are tested and reviewed properly. One of the reasons that it hasn't happened before is that we forced people who tried to make, or proposed making, such changes to make them in a compatible sort of way. We have all kinds of ugliness in and around FILE to try, alas in vain, to be compatible. One of the reasons people would like to see symbol versioning is to make it easier to change the size of different structures because we have stood on our heads in the past to not change sizes. I'm concerned that the empirical evidence from the past might not be a good thing to base our future plans upon. We knew we had sucky tools to deal with binary incompatibility in the past, so we stood on our heads to not make too many binary incompatible changes. With that limitation gone, I think the likelihood is large we will see multiple ABI changes between major releases on something. Especially since it happens when structures change size and there are many functions that take pointers to multiple structures... Warner