Re: What parts of UMA are part of the stable ABI?

On 18 March 2015 at 08:23, John Baldwin <jhb_at_freebsd.org> wrote:
> On Wednesday, March 18, 2015 11:19:21 AM Ryan Stone wrote:
>> On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin <jhb_at_freebsd.org> wrote:
>>
>> > I do think the normal zone callbacks passed to uma_zcreate() are too public
>> > to change.  Or at least, you would need to do some crazy ABI shim where you
>> > have a uma_zcreate_new() that you map to uma_zcreate() via a #define for
>> > the API, but include a legacy uma_zcreate() symbol that older modules can
>> > call (and then somehow tag the old function pointers via an internal flag
>> > in the zone and patch UMA to cast to the old function signatures for zones
>> > with that flag).
>> >
>>
>> I really wasn't clear here.  I definitely don't think that changing the
>> ctor, etc to accept a size_t is MFC'able, and I don't think that the
>> problem (which is really only theoretical at this point) warrants an MFC to
>> -stable.  I was talking about potentially doing it in a separate commit to
>> head, but that does leave -stable and head with a different API.  This can
>> be painful for downstream consumers to deal with, which is why I wanted
>> comments.
>
> I actually think the API change to fix the zone callbacks is fine to change
> in HEAD.  I don't think that is too disruptive for folks who might be
> sharing code across branches (they can use a local typedef to work around
> it or some such).

+1. This isn't exposed to userland, right? So I wouldn't worry about.

Kernel progress can't be held back because we're afraid of kernel ABI
changes that fix actual bugs.



-adrian