design choices for a loadable module interface

[Zhanna Tsitkova]

  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
"libaudit_bogus.so". 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. libaudit_bogus.so,
updates.

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, "plugin_XXX.so" that knows everything about  
underlying
functionality of, say, "libaudit_bogus.so". Alternatively, we can
statically link  plugin_XXX with  libaudit_bogus.so 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.

Thanks,
Zhanna


On May 26, 2010, at 10:45 AM, Tom Yu wrote:

> Nicolas Williams <Nicolas.Williams at oracle.com> 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 mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

Zhanna Tsitkova
tsitkova at mit.edu