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

[Thomas Hardjono]

Folks,

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.

http://k5wiki.kerberos.org/wiki/Projects/Plugin_support_improvements

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.

/thomas/


__________________________________________

> -----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 mit.edu
> 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
> 
> http://k5wiki.kerberos.org/wiki/Projects/Plugin_support_improvements
> 
> 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 mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev