Skip site navigation (1)Skip section navigation (2)
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>