[17252] in Kerberos_V5_Development
Re: GSS memory allocation initial cut for review
daemon@ATHENA.MIT.EDU (Nico Williams)
Wed Oct 5 14:36:29 2011
MIME-Version: 1.0
In-Reply-To: <tslbotvuzoz.fsf@mit.edu>
Date: Wed, 5 Oct 2011 13:25:46 -0500
Message-ID: <CAK3OfOhMtp0uLDBVRmghJvqWDkUj3FjRxBiecDVO-Ea0qB9cRg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Sam Hartman <hartmans@painless-security.com>
Cc: kevin.wasserman@painless-security.com, krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Wed, Oct 5, 2011 at 12:15 PM, Sam Hartman<hartmans@painless-security.com> wrote:> Nico> For any one mechglue implementors are free to do as they wish.> Nico> But I thought you wanted all mechglues on a platform to share> Nico> an allocator, and *that* would require some consensus among> Nico> implementors.>> I do, but my timely pressing concern is the changes to the MIT code.> For now we're calling heapalloc. But if the consensus is something else> and we've made changes to run allocations through one place it's easy to> match that consensus.> We presented the long-term plan only for context; the long-term> discussion needs to happen on kitten.> I've said this several times both on krbcore and krbdev.> Well, OK, I may have only said it once on krbdev, but that was in the> original message.
You know very well that I'm not on krbcore, so I've only made yourepeat yourself once :)
The original krbdev post is a bit unclear as to whether the part aboutall mechglues sharing an allocator is an immediate or long-term aspectof the proposal -- it does acknowledge the need for standardization,so I guess that's enough to conclude the latter.
BTW, has krbcore become a function of the consortium? With membershipa benefit to consortium members?
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
