design choices for a loadable module interface
jhutz at cmu.edu
Fri Jun 4 18:08:00 EDT 2010
--On Friday, June 04, 2010 04:51:18 PM -0500 Nicolas Williams
<Nicolas.Williams at oracle.com> wrote:
> Really, let's hear good reasons to not do the dlsym()-memoized-via-
> internal-vtables (which are then NOT part of the ABI). I can't think of
Well, it's about what happens when you want a single plugin to provide more
than one thing, like multiple related PA types or a PA type and an AD type
or whatever. As it is, you have specific "types" of extensions, the plugin
framework has to know what the types are and what the interface is to each
type, and you are restricted to each shared object containing exactly one
extension of exactly one type. A register_foo()-style interface eliminates
this tight binding and the corresponding abstraction violation (*). Of
course, the price is all of the problems you mentioned.
Once the design decision has been made that one-extension-per-shared-object
is acceptable, memoized-dlsym() definitely seems like the right answer.
(*) Of course, there are other ways to abstract knowledge of each plugin
ABI away from the plugin framework.
More information about the krbdev