design choices for a loadable module interface

[Tom Yu]

We are still working through some design issues related to an improved
plugin architecture.  We would like some input on what form a loadable
module interface should take.  This is the interface that would allow
a caller to do something like dynamically load a shared object at run
time, e.g. dlopen() on Unix-like systems.  We would not necessarily
immediately adopt such a loadable module interface for existing
pluggable interfaces, but would migrate toward it over time.

For some clarifications on terminology, see

http://k5wiki.kerberos.org/wiki/Projects/Plugin_support_improvements

The above wiki page is not a complete project proposal yet.  Please
let me know if the terminology requires additional clarification.

Below are several possible alternatives.  Please comment if you have
strong preferences among them.

* exported data symbol -- a vtable (a structure of function pointers)

  # We already use this for preauth and authdata plugins.
  
  # Shared object data symbols require extra relocation overhead on
    some platforms.

* exported function symbol(s)

  -- separate symbol for each interface function

     # Runtime symbol resolution can be slow on some platforms.

  -- one function that returns a vtable, possibly parameterized by
     version identifier

     # This may still require additional relocation overhead on some
       platforms.

     # Alternatively, have the function populate a passed-in
       caller-allocated vtable, possibly with a sanity check on the
       structure size.  This can still cause additional relocations,
       unless the function assigns the entries one at a time (e.g., by
       doing arithmetic on PLT entries), instead of copying from a
       prepopulated (private) struture.

Should different modules that implement the same interface each export
a different name?  If so, how would the caller discover the correct
name to pass to dlsym() or equivalent?

Relatedly, do we want to be able to use the same shared object as both
a loadable module and as a builtin?

Using different names per module might simplify linking the module as
a builtin, but the loader for builtin modules would still know how to
find it.