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>