Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Mar 2015 10:01:07 -0400
From:      John Baldwin <jhb@FreeBSD.org>
To:        Julian Elischer <julian@freebsd.org>,  Adrian Chadd <adrian@freebsd.org>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>, Ryan Stone <rysto32@gmail.com>
Subject:   Re: What parts of UMA are part of the stable ABI?
Message-ID:  <550AD6A3.1020406@FreeBSD.org>
In-Reply-To: <550A0B53.9020201@freebsd.org>
References:  <CAFMmRNypU_Y9UKDwpiRtedOCeCPQFOsVuswN0-rn3EmVykTAYw@mail.gmail.com> <2085699.T9kJlc0rkf@ralph.baldwin.cx> <CAFMmRNyYng0dai73KW9P1G%2BwqG=fvbhNpT-dRd9MHTeAK7wZzA@mail.gmail.com> <3923303.nkjJO958qy@ralph.baldwin.cx> <CAJ-VmokQ9AjScMw0bYHZRW8C6nLJQPSp0aqfYBH0=CL1EOC5qQ@mail.gmail.com> <550A0B53.9020201@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?550AD6A3.1020406>