design choices for a loadable module interface

[Russ Allbery]

Nicolas Williams <Nicolas.Williams at oracle.com> writes:
> On Tue, Jun 29, 2010 at 02:07:11PM -0700, Russ Allbery wrote:
>> ghudson at MIT.EDU writes:

>>> 1. Plan Nico: each dynamic plugin exports one function symbol per
>>> method.  The names are the same across all plugin implementations of
>>> an interface.

[...]
>> I prefer plan 2 because I think the ability to provide one module which
>> supports multiple different Kerberos versions is important, although I'm
>> not sure why one would use that plan as opposed to just exporting the

> Please explain how (1) doesn't allow that?

Perhaps I was misled by "the names are the same across all plugin
implementations of an interface."  I took that to mean that if we changed,
say, the function signature, we'd keep the same symbol for the function,
which would preclude supporting multiple versions in the same plugin.  But
maybe something different was meant by that?

> (1) does not preclude having a function by which a plugin can indicate
> what versions of the plugin interface it supports.  Even without such a
> function in the initial version, one could still determine what version
> of the interface is supported if the interface is evolved in such a way
> as to not create ambiguity, and one could add such a function at any
> time if it ever proved necessary.

> I especially dislike manually doing what the linker/loader already does.

The problem that I have with your proposal is precisely that the
linker/loader *cannot* check the ABI fully.  All it can check is whether
there's a symbol with the appropriate name, but that function may be
expecting a completely different set of arguments if that changed over
time.  When you call that function, you can then get segfaults or memory
clobbers or other nastiness.  I'm therefore skeptical of relying only on
the linker/loader.

With either the vtable or the function approach, you have to rename the
symbols whenever the signature changes.  With the vtable approach, you
encapsulate defined versions of the API in a single struct and know in the
plugin exactly which set of functions will be called together.  With the
function approach, you are essentially keeping track of that separately,
even if you rename functions when the API changes, and you potentially
open yourself to confusions that happen only if people mix old and new API
calls.

> Data symbols tend to have more issues than function symbols.  There's no
> GOT when it comes to data symbols, for example.  I once again left my
> copy of the linkers and loaders book at home.  I strongly recommend
> against using exported data symbols as part of any ABIs.

Given that both MIT and Heimdal are already successfully using exported
data symbols as part of their ABIs, I'd like to hear more concrete details
of what problems this is currently causing in practice before ruling this
out.  I assume that you're proposing moving away from this to solve some
set of problems that are currently affecting both major Kerberos
implementations?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>