Re: Symbol versioning errors in libthr

Hey, just because I'm ugly, hairy, and my knuckles scrape on the
ground is no reason to call me a monkey ;-)

On Mon, 4 Feb 2008, Dag-Erling Smørgrav wrote:

> Daniel Eischen <deischen_at_freebsd.org> writes:
>> Dag-Erling Smørgrav <des_at_des.no> writes:
>>> (unless you can show that it's actually harmful in some way?)
>> Please do not bump private, it was never meant to be bumped like this.
>
> This is not substantiation, this is the old monkey telling the young
> monkey "this is the way it's always been done".
>
> With all due respect to the old monkey, the young monkey simply can't
> understand why FBSD and FBSDprivate should be assymetric.

Linux doesn't even have a version for GLIBC_PRIVATE.  If we
take the same approach to FBSDprivate as we do FBSD, then
there is no need at all for FBSDprivate.

We don't want to add compatibility
hacks for anything in FBSDprivate (that is the purpose of
having private in the first place), so if you start
bumping private then you should also start adding compat
hacks - otherwise you have to edit old private versions
to remove (duplicate) symbols.

FBSDprivate is to allow us to change our internal ABIs without
really managing them - at least on the same level as the
public namespace.  If somehow something sneaks into private
that needs to be publicized, we are free to bump private,
but the goal is to not allow that to happen.

We've come from -current and previous releases where there
was no versioning at all, and have always managed.  Yes,
with some pain.  But I cannot forsee how using FBSDprivate
in the way we've designed it for (yes, it was reviewed)
is somehow going to make the sky fall one day.  And if there
is a problem, that is why we have -current.  We can iron it
out there, and bump private if it ever becomes necessary.
But we don't want to create more of a headache by maintaining
different versions of private symbols - the private namespace
allows us to add, remove, and change ABIs almost "willy nilly"
without burdoning ourselves.

This seems to be how it is done on both Solaris and Linux,
if you want an example of prior art.

> The young monkey would also like the old monkey to explain to him what
> harm will come of this (the young monkey has asked this already, but the
> old monkey has declined to respond).
>
> Finally, the young monkey would like to point out that this is all very
> poorly documented.  While aware of the freebsd_versioning.txt document
> written by the old monkey, the young monkey can't find anything in it
> about private symbol spaces.
>
> If the old monkey is in any way offended by this, he is free to
> s/old/mature and experienced/ :)

No, of course not.  I hope I don't come across as too
controntational either :-)

-- 
DE