design choices for a loadable module interface
Nicolas.Williams at oracle.com
Wed May 26 10:12:42 EDT 2010
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.
> > 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.
More information about the krbdev