design choices for a loadable module interface

[Russ Allbery]

Will Fiveash <will.fiveash at oracle.com> writes:
> On Tue, Jun 29, 2010 at 05:09:02PM -0700, Russ Allbery wrote:

>> Those of us who write plugins that support multiple Kerberos
>> implementations will just write stub functions to fit the MIT Kerberos
>> plugin ABI that call other functions anyway, so you're going to have a
>> similar problem with vtables or without them.

> One would hope the stub would live in the same file as the actual method
> which is still a more straightforward way of locating method
> definitions.

I normally would not do so, no.  I write the core module code to a
reasonable internal API and then have separate mit.c and heimdal.c files
that contain the required glue to make it conform to the plugin interface
of those Kerberos implementations.  This makes it simpler from a build
system perspective to build only the required code for the Kerberos
implementation being targetted, since that shim code often is specific to
that Kerberos implementation and won't build on the other.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>