[15838] in Kerberos_V5_Development
design choices for a loadable module interface
daemon@ATHENA.MIT.EDU (Tom Yu)
Tue May 25 18:06:35 2010
To: krbdev@mit.edu
From: Tom Yu <tlyu@mit.edu>
Date: Tue, 25 May 2010 18:06:31 -0400
Message-ID: <ldvvdabtz4o.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
