Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 04 Aug 2016 22:21:20 -0700
From:      Jordan Hubbard <jordanhubbard@me.com>
To:        Julian Elischer <julian@freebsd.org>
Cc:        John Baldwin <jhb@freebsd.org>, Bryan Drewery <bdrewery@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r303755 - head/sys/kern
Message-ID:  <07795F0C-E421-4E7C-89FB-31D43BF563FB@me.com>
In-Reply-To: <03c923dd-4161-43ea-6249-b7b2b61e660f@freebsd.org>
References:  <201608041914.u74JEIOR071062@repo.freebsd.org> <1631194.6AMpXoHEiR@ralph.baldwin.cx> <03c923dd-4161-43ea-6249-b7b2b61e660f@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

> On Aug 4, 2016, at 10:06 PM, Julian Elischer <julian@freebsd.org> =
wrote:
>=20
> personally I'd rather we drove a stake through the heart of symbol =
versioning and
> went back to how it was, when one could work out what was going on.
> I certainly miss the ability to get the openssl package to overwrite =
the base one,
> which I'm told is no longer possible due to versioning.

That seems unlikely to be a strategy for long-term success given all of =
the opportunities for *unintentional* overwriting of symbols.  In other =
words, it=92s great when it works for you.  It sucks when it works =
against you.

That said, in OS X, Solaris-style symbol versioning didn=92t really =
yield a lot of dividends and turned out to be a far-too-granular way of =
permuting APIs over time.  What tended to happen instead was that =
symbols got renamed through header hacks (=93aliasing=94) and the old =
binaries simply continued to work by calling different versions of =
function X (newly compiled applications talking to the new =
implementation).

What HAS yielded a lot of dividends in OS X is a two-level namespace for =
all symbols.  To quote the Apple docs:  "The two-level namespace feature =
of OS X v10.1 and later adds the module name as part of the symbol name =
of the symbols defined within it. This approach ensures a module=92s =
symbol names don=92t conflict with the names used in other modules.=94

This prevents other problems and allows you to move symbols around =
en-masse in refactoring exercises rather than having to version them.  =
If FreeBSD is genuinely =93fed up=94 with ELF symbol versioning, I might =
suggest that other alternatives be explored rather than simply going =
back to the Bad Old Days because they were more predictable.

- Jordan




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?07795F0C-E421-4E7C-89FB-31D43BF563FB>