design choices for a loadable module interface

Nicolas Williams Nicolas.Williams at
Wed May 26 10:59:10 EDT 2010

On Wed, May 26, 2010 at 10:45:03AM -0400, Tom Yu wrote:
> Nicolas Williams <Nicolas.Williams at> writes:
> > On Wed, May 26, 2010 at 10:00:24AM -0400, Greg Hudson wrote:
> >> 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?
> By built-in, I mean that the plugin module is part of the library
> shared object or program executable that calls the module.  I'll
> update the wiki page.

Right, so, statically linked into the library (though the library itself
is a shared object).  OK, "statically linked" is not the best term since
developers are likely to think of the application as being statically
linked, or the library being a static link archive -- we need a new

But the point is that the mechanism by which you get at "builtin"
modules is going to be very much the same kind of mechanism you'd use to
get at plugins if you had to statically link everything.

More information about the krbdev mailing list