mechglue registration of gss_buffer_t pointers

[Sam Hartman]

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    Nicolas> On Mon, Oct 22, 2007 at 07:39:21PM -0400, Sam Hartman
    Nicolas> wrote:
    >> Tom, when I discussed this proposal with Nico he indicated he
    >> had significant performance concerns.  Perhaps we can get him
    >> to comment on these concerns.

    Nicolas> You just did :)

    Nicolas> Solaris has a kernel mechglue and high rates of
    Nicolas> gss_buffer_t allocations and deallocations in the kernel.
    Nicolas> I'm afraid that buffer registration schemes simply won't
    Nicolas> be acceptable.  Besides, user-land libgss should support
    Nicolas> high rates of gss_buffer_t allocations and deallocations.

What can we do to figure out how well we could do with a registration
mechanism and what performance is required?

    Nicolas> There are several things we could do.  Here's two:

    Nicolas>  - Play linker games to ensure there's a single
    Nicolas> gss_allocator for the mechglue and all mechs

One problem with this is that it makes it difficult to use language-specific allocation mechanisms.  You'd like to be able to use new in C++ or the corresponding Objective C mechanisms if you write a mech in those languages.

    Nicolas>    If you're willing to not require that mechs be
    Nicolas> complete GSS-API implementations that can be used both,
    Nicolas> standalone as a plug-in to the mechglue, then you can
    Nicolas> increase the number of OSes where you can make this work.
    Nicolas> On OSes where you can't play any such games you could
    Nicolas> resort to using static linking only.


    Nicolas>  - Require that all buffers that can be passed to
    Nicolas> gss_release_buffer() have a header before the actual
    Nicolas> buffer that points to the destructor function to use


    Nicolas> Nico --