design choices for a loadable module interface
Nicolas.Williams at oracle.com
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