design choices for a loadable module interface

[Nicolas Williams]

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
--