[15847] in Kerberos_V5_Development
RE: design choices for a loadable module interface
daemon@ATHENA.MIT.EDU (Zhanna Tsitkova)
Thu May 27 21:35:46 2010
From: Zhanna Tsitkova <tsitkova@mit.edu>
To: Tom Yu <tlyu@mit.edu>
Date: Thu, 27 May 2010 21:35:35 -0400
Message-ID: <8DD7AD829AB61E499A433D6E558110A301EF3C9C48@EXPO7.exchange.mit.edu>
In-Reply-To: <ldvvda9p6ra.fsf@cathode-dark-space.mit.edu>
Content-Language: en-US
MIME-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>,
Nicolas Williams <nicolas.williams@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
My answers are prefixed with ##
________________________________________
From: Tom Yu [tlyu@MIT.EDU]
Sent: Thursday, May 27, 2010 1:57 PM
To: Zhanna Tsitkova
Cc: Nicolas Williams; krbdev@mit.edu
Subject: Re: design choices for a loadable module interface
Zhanna Tsitkova <tsitkova@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
> "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.
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, "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.
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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
