From owner-cvs-all@FreeBSD.ORG Tue Aug 28 04:31:44 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 5C8A116A419; Tue, 28 Aug 2007 04:31:44 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0D4D413C46A; Tue, 28 Aug 2007 04:31:43 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l7S4VWK4025780; Tue, 28 Aug 2007 00:31:32 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Tue, 28 Aug 2007 00:31:33 -0400 (EDT) Date: Tue, 28 Aug 2007 00:31:32 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "M. Warner Losh" In-Reply-To: <20070827.204618.-1350500405.imp@bsdimp.com> Message-ID: References: <20070828004842.GT21352@comp.chem.msu.su> <20070827.204618.-1350500405.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Reply-To: Daniel Eischen 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 04:31:44 -0000 On Mon, 27 Aug 2007, M. Warner Losh wrote: > In message: > Daniel Eischen writes: > : 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... The emphasis should be on trying to get things right, tested, and reviewed the first time ;-) But also to keep compat shims to a minimum too. It may be easier to create different versions and keep compatibility, but the SV'd libraries are going to grow with compat shims if we don't try to reduce ABI changes like we've done in the past. I think we need an ABI review board monitored by -standards ;-) If you are really concerned about it (I'm not!), then you can always add another version in between releases, or just bump the version every time you break an ABI in -current. I'm not advocating this because I don't think it's necessary. I don't think you need to have both private and public versions in -current, just use 1.x and bump x for every ABI change. -current will always have all versions 1.0 - 1.x, and prior branches will have some of them. Whenever -current is branched, both the branch and -current will once again have all versions until the ABI in -current changes again. -- DE