[15932] in Kerberos_V5_Development
Re: design choices for a loadable module interface
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Tue Jun 29 17:31:50 2010
Date: Tue, 29 Jun 2010 16:30:59 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Russ Allbery <rra@stanford.edu>
Message-ID: <20100629213058.GA11785@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8739w5im4g.fsf@windlord.stanford.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Tue, Jun 29, 2010 at 02:07:11PM -0700, Russ Allbery wrote:
> 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
Please explain how (1) doesn't allow that?
(1) does not preclude having a function by which a plugin can indicate
what versions of the plugin interface it supports. Even without such a
function in the initial version, one could still determine what version
of the interface is supported if the interface is evolved in such a way
as to not create ambiguity, and one could add such a function at any
time if it ever proved necessary.
I especially dislike manually doing what the linker/loader already does.
> 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.
Data symbols tend to have more issues than function symbols. There's no
GOT when it comes to data symbols, for example. I once again left my
copy of the linkers and loaders book at home. I strongly recommend
against using exported data symbols as part of any ABIs.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
