From owner-cvs-all@FreeBSD.ORG Fri Dec 14 16:31:48 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 1780016A420 for ; Fri, 14 Dec 2007 16:31:48 +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 AAD6F13C44B for ; Fri, 14 Dec 2007 16:31:47 +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.2/8.14.2/NETPLEX) with ESMTP id lBEGVkI1021197; Fri, 14 Dec 2007 11:31:46 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 14 Dec 2007 11:31:46 -0500 (EST) Date: Fri, 14 Dec 2007 11:31:46 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Schultz In-Reply-To: <20071214083507.GA33635@VARK.MIT.EDU> Message-ID: References: <200712140308.lBE38Ae7061160@repoman.freebsd.org> <20071213235617.2b554b60@kan.dnsalias.net> <20071214083507.GA33635@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Yar Tikhiy , Alexander Kabaev , cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/msun Symbol.map 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: Fri, 14 Dec 2007 16:31:48 -0000 On Fri, 14 Dec 2007, David Schultz wrote: > On Fri, Dec 14, 2007, Daniel Eischen wrote: >> I think we reached some sort of consensus that the namespace would be >> bumped for every release...? So unless these get added to 7.0 before >> it goes out the door, they should be put in a separate namespace. >> >> On the other hand, newly added symbols don't break the ABI. I >> don't think there is a technical reason why symbols can't be >> added to FBSD_1.0 in -current; they can be easily backported >> to 7.0. > > The only reason I can think of---and perhaps this is why Alex was > objecting---is that someone could write a library that exports a > symbol with the same name but a different purpose. Then a binary > that was linked against both that library and libm.so.5 could get > different results on later versions of FreeBSD. No, that's not the reason - see Alex' other email. >> At a minimum, we need to create one new namespace in each >> release branched from -current when there is one or more >> ABI changes from the prior release. Perhaps we should just >> move to FBSD_1.1 now in 8-current just to make things easier. >> When we go to 9-current, we move to FBSD_1.2, etc. If you >> need to backport changes back to 7.x, then you also have to >> create the matching version in 7.x. > > The trouble with that is that if I MFC one thing now and another > thing between 7.0-RELEASE and 7.1-RELEASE, then people can just as > easily complain that I polluted the FBSD_1.1 namespace. The only > pedantically correct resolution I can think of is to add a new > version for each new symbol that I might possibly ever want to > MFC. (Usually I don't plan on MFCing due to limited time, but > ports maintainers sometimes ask. This happens less now that we're > free from the overly long 4.x release cycle.) No, everytime we branch a release from -current (e.g, at 8.0, 9.0, etc), we should increment the namespace. -current typically stays at the same number for quite a while (1-3 years?). We go to FBSD_1.1 now in 8-current. Check with re@ and see if you can MFC your symbols before 7.0. If not, then move them to FBSD_1.1 in -current. If you have to MFC symbols from FBSD_1.1 in -current, then just add those symbols to FBSD_1.1 in 7.x. Whatever happens, the symbols in release N.x must be present in the same namespaces as release N.x+y through -current to maintain backward compatibility. The opposite is not true, as release N.x+y can contain a superset of symbols from release N.x. -- DE