Plugin project proposal (work in progress) -- RE: design choices for a loadable module interface

Thomas Hardjono hardjono at MIT.EDU
Fri Jul 9 12:15:52 EDT 2010


Following Tom's message on an improved plugin architecture (May 25),
there is now a Project Proposal page on the wiki written
by Zhanna Tsitkova (MITKC) who is the inceptor of this project.

Since this project proposal text could be considered an 
early or "alpha" version (work in progress), we would like to get
your feedback on the proposal.



> -----Original Message-----
> From: krbdev-bounces at MIT.EDU [mailto:krbdev-bounces at MIT.EDU] On Behalf
> Of Tom Yu
> Sent: Tuesday, May 25, 2010 6:07 PM
> To: krbdev at
> Subject: design choices for a loadable module interface
> We are still working through some design issues related to an improved
> plugin architecture.  We would like some input on what form a loadable
> module interface should take.  This is the interface that would allow a
> caller to do something like dynamically load a shared object at run
> time, e.g. dlopen() on Unix-like systems.  We would not necessarily
> immediately adopt such a loadable module interface for existing
> pluggable interfaces, but would migrate toward it over time.
> For some clarifications on terminology, see
> The above wiki page is not a complete project proposal yet.  Please let
> me know if the terminology requires additional clarification.
> Below are several possible alternatives.  Please comment if you have
> strong preferences among them.
> * exported data symbol -- a vtable (a structure of function pointers)
>   # We already use this for preauth and authdata plugins.
>   # Shared object data symbols require extra relocation overhead on
>     some platforms.
> * exported function symbol(s)
>   -- separate symbol for each interface function
>      # Runtime symbol resolution can be slow on some platforms.
>   -- one function that returns a vtable, possibly parameterized by
>      version identifier
>      # This may still require additional relocation overhead on some
>        platforms.
>      # Alternatively, have the function populate a passed-in
>        caller-allocated vtable, possibly with a sanity check on the
>        structure size.  This can still cause additional relocations,
>        unless the function assigns the entries one at a time (e.g., by
>        doing arithmetic on PLT entries), instead of copying from a
>        prepopulated (private) struture.
> Should different modules that implement the same interface each export
> a different name?  If so, how would the caller discover the correct
> name to pass to dlsym() or equivalent?
> Relatedly, do we want to be able to use the same shared object as both
> a loadable module and as a builtin?
> Using different names per module might simplify linking the module as a
> builtin, but the loader for builtin modules would still know how to
> find it.
> _______________________________________________
> krbdev mailing list             krbdev at

More information about the krbdev mailing list