mechglue registration of gss_buffer_t pointers

[Nicolas Williams]

On Mon, Oct 22, 2007 at 07:39:21PM -0400, Sam Hartman 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.

You just did :)

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

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

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

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


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


Nico
--