design choices for a loadable module interface

Zhanna Tsitkova tsitkova at MIT.EDU
Wed May 26 11:17:09 EDT 2010

  dynamic plugins - two cases:

1.  plugin itself is built-in, but loads a shared library. Example
here would be say, "audit plugin"  that dynamically loads some
"". For this case I suggested to have "separate
symbol for each interface function".  (yesterday I meant this case
when I was talking about the dynamic libs). The benefit of this kind
of plugin is the pain-free shared library. i.e.,

2. plugin itself is a dynamic lib: This one should be very similar to
what we have for static plugins in the new plugin architecture. Plugin  
impl would be
a shared lib. Here one has two options. One is to build  just a very
small library say, "" that knows everything about  
functionality of, say, "". Alternatively, we can
statically link  plugin_XXX with and treat it as a  
dynamically loadable plugin. Obviously, the only interface this plugin
would have is  plugin_XXX_create. Trick here is to pass the ref info
to plugin_manager.


On May 26, 2010, at 10:45 AM, 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.
> _______________________________________________
> krbdev mailing list             krbdev at

Zhanna Tsitkova
tsitkova at

More information about the krbdev mailing list