design choices for a loadable module interface

[Nicolas Williams]

On Thu, Jun 03, 2010 at 04:38:25AM -0400, Jeffrey Hutzelman wrote:
> Yeah.  Or do everything via published register_foo() interfaces, and
> have each plugin publish an init function which is called when the
> plugin is loaded, or at startup for built-in plugins.  Of course the
> init functions for builtins might have to have per-plugin names, in
> which case it'd be relatively straightforward to generate a function
> which calls the init functions of all the builtin plugins.
> 
> Or they could be static but included in some magic global table of
> init functions to be called, possibly constructed by putting their
> addresses into a separate ELF section, one address per plugin
> object, with the startup code using the base address and length of
> that section to find the table.

A register_foo() approach combines the worts of all worlds.  You need to
use dlsym() on a well-known name so you can call a plugin's init
function that will then register, unless you do this from .init sections
(which I _strongly_ recommend agaisnt doing [0]).  And you still need a
vtable to be part of the ABI _or_ the plugin has to call register_foo()
once per-function, at which point you have to wonder: why on Earth
replicate what should be framework code in all plugins?

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.

[0] http://blogs.sun.com/rie/entry/init_and_fini_processing_who

Nico
--