design choices for a loadable module interface

Nicolas Williams Nicolas.Williams at
Tue Jun 29 17:30:59 EDT 2010

On Tue, Jun 29, 2010 at 02:07:11PM -0700, Russ Allbery wrote:
> ghudson at MIT.EDU writes:
> > 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 vtable).
> 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?

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

> vtable as the public symbol and naming the vtable public symbol to include
> the ABI.  I rather liked that approach; I thought it worked quite well and
> was nicely straightforward.

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.


More information about the krbdev mailing list