design choices for a loadable module interface

[Nicolas Williams]

On Fri, Jun 04, 2010 at 06:08:00PM -0400, Jeffrey Hutzelman wrote:
> --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
> >any.
> 
> 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.

I thought that's where you were heading.

First: avoid .init/.fini ELF sections and equivalents on any non-ELF
platform.  I think this is a good rule no matter what.

Second: dlsym()+one-plugin-per-object is a good design.  If you must
have multiple plugins of different types in the same object then that's
easy to handle: it's just a matter of configuration (or links, if
directory listings _are_ the configuration).  If you really must have
multiple plugins of the same type in the same object, then format the
plugin name into the symbol name.

The KISS principle works here and gets you what you're looking for
without having to resort to vtables in the ABI or unnecessary
complications.

> Once the design decision has been made that
> one-extension-per-shared-object is acceptable, memoized-dlsym()
> definitely seems like the right answer.

See above.

Nico
--