mechglue registration of gss_buffer_t pointers
hartmans at MIT.EDU
Tue Oct 23 09:29:08 EDT 2007
>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
Nicolas> On Mon, Oct 22, 2007 at 07:39:21PM -0400, Sam Hartman
>> 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 --
More information about the krbdev