[15930] in Kerberos_V5_Development
Re: design choices for a loadable module interface
daemon@ATHENA.MIT.EDU (Russ Allbery)
Tue Jun 29 17:07:14 2010
From: Russ Allbery <rra@stanford.edu>
To: krbdev@mit.edu
In-Reply-To: <201006292056.o5TKuwhO013320@outgoing.mit.edu> (ghudson@mit.edu's
message of "Tue, 29 Jun 2010 16:56:58 -0400 (EDT)")
Date: Tue, 29 Jun 2010 14:07:11 -0700
Message-ID: <8739w5im4g.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
ghudson@MIT.EDU writes:
> Based on some internal discussions, I think this conversation needs to
> be continued slightly and summarized. To simplify the summary, here are
> two concrete ABI design shapes:
> 1. Plan Nico: each dynamic plugin exports one function symbol per
> method. The names are the same across all plugin implementations of
> an interface.
> 2. Plan Simo: each dynamic plugin exports an init function, whose is
> constructed based on the plugin implementation name (e.g. "db2_kdb_init"
> for the DB2 KDB module, "ldap_kdb_init" for the LDAP KDB module). The
> init function accepts a version number and outputs a structure full of
> function pointers for the methods (aka vtable).
I prefer plan 2 because I think the ability to provide one module which
supports multiple different Kerberos versions is important, although I'm
not sure why one would use that plan as opposed to just exporting the
vtable as the public symbol and naming the vtable public symbol to include
the ABI. I rather liked that approach; I thought it worked quite well and
was nicely straightforward.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
