Mechanism extensions and the GSSAPI

Sam Hartman hartmans at MIT.EDU
Mon May 3 16:29:11 EDT 2004

>>>>> "Christopher" == Christopher  <cmaxwell at> writes:

    Christopher> On Mon, 3 May 2004, Sam Hartman wrote:
    >> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at>
    >> writes:
    Nicolas> On Mon, May 03, 2004 at 02:26:54PM -0400, Sam Hartman
    Nicolas> wrote:
    >> >> And yet none of these are useful if we are specifying at the
    >> >> shim layer.
    Nicolas> Specifying at the shim layer.  I'll have to think about
    Nicolas> that.
    >>  If we don't specify at the shim layer, then we cannot depend
    >> on the shims being present.  That means that people are forced
    >> to code to the ioctls, which makes extensions hard to use.

    Christopher> Maybe this is oversimplistic, but why not provide the
    Christopher> shims as library/source to be linked into the
    Christopher> application that deal with the ioctls below the
    Christopher> applications view of them?

This seems more complex for authors of applications than being able to
depend on shims being present.

ALso, it means you need to specify a stable, extensible protocol
between the shim and the mechanism.  That's significant work that you
avoid by making the ioctl specification a mechanism implementation

More information about the krbdev mailing list