Mechanism extensions and the GSSAPI

[Nicolas Williams]

On Thu, Apr 29, 2004 at 11:09:00AM -0400, Kevin Coffman wrote:
> > 			  Shim around Ioctl

> I think I agree with Nico that this seems like the best option, but
> let me see if I fully comprehend.
> 
> - When building the application, you need to know whether it is
> linking against a single-mechanism gssapi implementation or a
> multi-mechanism glue layer.  Either way, it's interface doesn't
> change. 
>
> - If the app is linking directly with the single-mech
> implementation, and uses mech-specific functions, it all happily
> works.
> 
> - If the app is linking with the multi-mechanism "core glue" and
> uses mech-specific functions, it needs to know to link with the
> mech-specific "glue shim(s)" and not directly against the mech-specific
> library. (i.e. the "core glue" library shouldn't have to know about
> mech-specific glue shims.)
> 
> Is this what you were thinking?

I think the utility "shims" around "ioctl" could/should/would live in a
separate library.

Remember, the API for a mechglue layer and the SPI for a mechanism are
the same -- the GSS-API -- in this model, so whether you link directly
against a mechanism or against the mechglue need not be decided until
run-time (think LD_PRELOAD).  But those utility functions have to be in
some library, and since you wouldn't want them in every GSS-API
implementation (mechglue and mechs) you'd want them in a separate
library instead.

Nico
--