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

On 3/18/15 7:33 PM, Julian Elischer wrote:
> On 3/19/15 3:28 AM, Adrian Chadd wrote:
>> 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.
> 
> I don't think we've ever aid we'd maintain kernel internal ABI across 
> different code lines.
> We have said we'd try  keep changes to some things
> "easy to fix" (e.g. network driver API) but a recompile is pretty much 
> always needed.

This is not about maintaining the ABI across branches.  This is about whether
or not a change can be merged to stable/10 and what kinds of ABI breakages
are acceptable in stable/10.

As I said three quote levels up, I am _in favor_ of changing the API in HEAD
and that that level of API change is not too disruptive for folks who try to
keep a single code base that compiles across multiple branches.  For these
folks, ABI changes don't really matter, but API changes do have to be coped
with.  For a prime example, grep for FreeBSD_version in the Intel NIC drivers
(several storage drivers from external vendors such as twa and hpt* also have
various local compat shims to handle API changes).

-- 
John Baldwin