[15879] in Kerberos_V5_Development
Re: design choices for a loadable module interface
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Fri Jun 4 17:51:33 2010
Date: Fri, 4 Jun 2010 16:51:18 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Message-ID: <20100604215118.GX9605@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <81F8CDB605178192D9D28641@lysithea.fac.cs.cmu.edu>
Cc: krbdev@mit.edu, Tom Yu <tlyu@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
