design choices for a loadable module interface

[Nicolas Williams]

On Wed, May 26, 2010 at 10:00:24AM -0400, Greg Hudson wrote:
> 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).

Well, I don't understand what you mean by "builtin" then.  Can you give
me more of a sketch?

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

This is a library that does _crypto_ and involves DNS lookups, sending
datagrams to KDCs or connecting to them via TCP...  I don't think the
cost of a few dlsym() calls is going to be noticed.

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

Can you show that dlsym() is a problem, anywhere?

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

It's not.

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

You know, what existed before shared objects.  See ar(1), ld(1), ...

> really supported static library loading and linking for some time (aside
> from an experiment I did with code coverage testing).

Oh, well, good!

> If by the above statement you mean "dynamically load every plugin
> implementation, with no builtins," that's a possibility, I suppose.  It

I didn't.  What's a builtin?

> would mean basically no part of Kerberos can work on a platform where we
> can't get dynamic loading to work.

Nico
--