design choices for a loadable module interface

Zhanna Tsitkova tsitkova at MIT.EDU
Thu May 27 21:35:35 EDT 2010

My answers are prefixed with ##
From: Tom Yu [tlyu at MIT.EDU]
Sent: Thursday, May 27, 2010 1:57 PM
To: Zhanna Tsitkova
Cc: Nicolas Williams; krbdev at
Subject: Re: design choices for a loadable module interface

Zhanna Tsitkova <tsitkova at MIT.EDU> writes:

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

Do you mean that from the perspective of the plugin framework, the
plugin module behaves as if it were built in, but its implementation
actually does a dlopen() of some shared object?  
## Yes

How does it find the shared object file, 

## it gets the path info from the plugin configuration.

and why isn't the task of loading the module left to the plugin framework?

## plugin takes care about its own stuff. This task is irrelevant to plugin framework. 

> 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
> underlying
> functionality of, say, "". Alternatively, we can
> statically link  plugin_XXX with and treat it as a
> new
> 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.

Which of these would be the runtime-loadable shared objects, and which
ones would be dependencies of the calling library (or program)?

## dyn loadable plugin impl  is loaded  during run-time. 

More information about the krbdev mailing list