What parts of UMA are part of the stable ABI?
jhb at FreeBSD.org
Thu Mar 19 14:01:10 UTC 2015
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
>>> 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).
More information about the freebsd-current