design choices for a loadable module interface

ghudson@MIT.EDU ghudson at MIT.EDU
Tue Jun 29 16:56:58 EDT 2010

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.

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

Some arguments in favor of each shape:

* Plan Nico requires the least amount of code for a dynamic plugin

* Plan Nico allows you to add new methods while retaining
  compatibility with old plugins, as long as the new methods are

* 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

* 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.

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

More information about the krbdev mailing list