mechglue registration of gss_buffer_t pointers
Nicolas Williams
Nicolas.Williams at sun.com
Mon Oct 22 19:46:34 EDT 2007
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
--
More information about the krbdev
mailing list