design choices for a loadable module interface

[Nicolas Williams]

On Tue, Jun 29, 2010 at 04:56:58PM -0400, ghudson at mit.edu wrote:
> Based on some internal discussions, I think this conversation needs to
> be continued slightly and summarized.  To simplify the summary, here
> are two concrete ABI design shapes:
> 
> 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 had also explained, and I'll repeat now, that for platforms that lack
dynamic linker loaders you could effectively build your own that takes a
function export list and plugin sources and auto-generates a v-table,
with everything statically linked.  The framework and plugin code would
remain untouched, using shim dlopen()/dlsym() functions.

My complaint about all other alternatives is that we'll wind up with all
sorts of redundant code, replicating dynamic linker loader functionality
when there's no need for it, making it harder to develop and easier to
screw up.

> 2. Plan Simo: each dynamic plugin exports an init function, whose is
> constructed based on the plugin implementation name
> (e.g. "db2_kdb_init" for the DB2 KDB module, "ldap_kdb_init" for the
> LDAP KDB module).  The init function accepts a version number and
> outputs a structure full of function pointers for the methods (aka
> vtable).

See above.  Simo's plan can be used as a backup, with auto-generated
code (so no one has to deal with populating v-tables), for OSes that
don't support dynamic loading.

> Some arguments in favor of each shape:
> 
> * Plan Nico requires the least amount of code for a dynamic plugin
>   implemention.
> 
> * Plan Nico allows you to add new methods while retaining
>   compatibility with old plugins, as long as the new methods are
>   optional.
> 
> * Plan Simo potentially requires zero changes to the implementation
>   source code to make it built into the consumer rather than
>   dynamically loaded.  This is interesting for deployments with
>   no-shared-library requirements, and possibly also for portability to
>   Windows.

I strongly believe that this is false, at least in so far as the
implication that my approach requires more work to get it to link
statically Simo's requires in any one case.

> * If there are incompatible changes to a pluggable API across versions
>   of Kerberos (not just adding new optional methods), Plan Simo makes
>   it possible, though perhaps difficult, to provide a shared object
>   which works with multiple Kerberos versions.  This is most
>   interesting for the DAL, where we have no stability guarantees and
>   know we want to make lots of big changes.

Simo's plan makes it possible to detect incompatibility and thus fail to
load an old/new plugin.  It also makes it possible to retain
multi-version support in the framework.  But, so does mine.

> * Plan Simo makes it potentially easier to set breakpoints at specific
>   method implementations.  This is a pretty minor point, as there are
>   good workarounds.

If you're using dynamic linking at all then there's no difference in how
hard it is to set such breakpoints in either scheme.  If you don't agree
then please explain in detail.

Nico
--