[15851] in Kerberos_V5_Development
Re: design choices for a loadable module interface
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Fri May 28 13:34:06 2010
Date: Fri, 28 May 2010 12:32:43 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Sam Hartman <hartmans@mit.edu>
Message-ID: <20100528173242.GO9605@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tslfx1cvt8w.fsf@mit.edu>
Cc: krbdev@mit.edu, Tom Yu <tlyu@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Fri, May 28, 2010 at 01:19:43PM -0400, Sam Hartman wrote:
> I will note this is a departure from the approach we took for the
> preauth plugins and that was a concious decision, although I don't
> remember whether it was our decision or simply something we accepted
> when we accepted the code from RH. The authdata interface was
> explicitly modeled on the preauth interface.
The Solaris libgss SPI uses a v-table. I put an end to that a while
back (4 years ago??) by making it so that for additions it just dlsym()s
each function, while internally keeping a v-table just to memoize the
dlsym() results.
The reason I made that change was this: I had to add an extension and
that meant patching not just libgss and mech_krb5, but also mech_dh* and
mech_spnego, even though those mechanisms weren't going to implement
that extension. Yes, I could hav resorted to some v-table versioning
scheme, but I also resented having to write and maintain all that static
content that the linker could take care of for me.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
