[15945] in Kerberos_V5_Development
Re: design choices for a loadable module interface
daemon@ATHENA.MIT.EDU (Russ Allbery)
Tue Jun 29 20:53:51 2010
From: Russ Allbery <rra@stanford.edu>
To: Nicolas Williams <Nicolas.Williams@oracle.com>
In-Reply-To: <20100630003222.GE2232@sun.com> (Will Fiveash's message of "Tue,
29 Jun 2010 19:32:22 -0500")
Date: Tue, 29 Jun 2010 17:53:47 -0700
Message-ID: <87iq51e3xg.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Will Fiveash <will.fiveash@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@stanford.edu) <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
