Re: Symbol versioning errors in libthr

From: David Schultz <das_at_FreeBSD.ORG>
Date: Mon, 4 Feb 2008 14:08:00 -0500
On Mon, Feb 04, 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.

The private namespace is a repository for symbols that we don't
intend to support across releases; these symbols may change or go
away, and applications shouldn't use them directly. Making
multiple private namespaces implies that the private namespaces
*are* stable according to some definition, hence why we need more
than one of them. Having stronger requirements for private
namespaces would seem to defeat the purpose and create more work
for people, principally Dan, who is still working with re_at_ to get
the FBSD_1.0 symbols right for 7.0-RELEASE. Perhaps you could
explain what stability requirements you have in mind for
FBSDPrivate_X.Y here.

> 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/ :)

This is a little bit more sarcastic and pretentious than needed.
Have a banana.  `-=-'

--the small monkey in the corner
Received on Mon Feb 04 2008 - 18:37:14 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:26 UTC