design choices for a loadable module interface

[Greg Hudson]

On Tue, 2010-05-25 at 18:56 -0400, Nicolas Williams wrote:
> I assume that by "builtin" you mean "statically linked in".

Actually, to avoid circular dependencies, I think builtin
implementations may need to be part of the library or program which
"loads" them.  Dynamically loaded plugins can make circular references
to the loading library, but linked libraries cannot (in general).

> I strongly recommend against exported data symbols in an SPI.

I'll note that we're using exported data symbols (containing vtables) in
most of our current plugin interfaces, without obvious ill effects.  I
don't actually like it, though; it makes graceful versioning harder.

> >      # Runtime symbol resolution can be slow on some platforms.
> 
> But it's one-time.  The framework should memoize the dlsym() calls.

For a long-running process, a bunch of memoized dlsym() calls should be
negligible.  I do worry about the case of, say, a script running
kadmin.local hundreds of times, in a world where the KDB plugin
framework has to dlsym() every DAL operation.

The performance overhead could perhaps be addressed by lazy resolution
of symbols.  So in the example above, kadmin.local would only have to
dlsym() a few DAL symbols per run because each operation doesn't
exercise very much of the DAL.

I don't really have a sense of how slow dlsym() can be.  If we're
talking up to a few hundred ms per call, that could get ugly quickly.
But I doubt it's *that* bad.

> I realize you can't ditch static linking for some of your users, so I'll
> refrain from offering that as an alternative :)

I'm still not sure what you mean by "static linking."  krb5 hasn't
really supported static library loading and linking for some time (aside
from an experiment I did with code coverage testing).

If by the above statement you mean "dynamically load every plugin
implementation, with no builtins," that's a possibility, I suppose.  It
would mean basically no part of Kerberos can work on a platform where we
can't get dynamic loading to work.