Date: Fri, 14 Dec 2007 11:31:46 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: David Schultz <das@freebsd.org> Cc: Yar Tikhiy <yar@freebsd.org>, Alexander Kabaev <kabaev@gmail.com>, cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/msun Symbol.map Message-ID: <Pine.GSO.4.64.0712141118200.16719@sea.ntplx.net> In-Reply-To: <20071214083507.GA33635@VARK.MIT.EDU> References: <200712140308.lBE38Ae7061160@repoman.freebsd.org> <20071213235617.2b554b60@kan.dnsalias.net> <Pine.GSO.4.64.0712140024230.14620@sea.ntplx.net> <20071214083507.GA33635@VARK.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0712141118200.16719>