Date: Wed, 18 Mar 2015 12:28:07 -0700 From: Adrian Chadd <adrian@freebsd.org> To: John Baldwin <jhb@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: <CAJ-VmokQ9AjScMw0bYHZRW8C6nLJQPSp0aqfYBH0=CL1EOC5qQ@mail.gmail.com> In-Reply-To: <3923303.nkjJO958qy@ralph.baldwin.cx> References: <CAFMmRNypU_Y9UKDwpiRtedOCeCPQFOsVuswN0-rn3EmVykTAYw@mail.gmail.com> <2085699.T9kJlc0rkf@ralph.baldwin.cx> <CAFMmRNyYng0dai73KW9P1G%2BwqG=fvbhNpT-dRd9MHTeAK7wZzA@mail.gmail.com> <3923303.nkjJO958qy@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokQ9AjScMw0bYHZRW8C6nLJQPSp0aqfYBH0=CL1EOC5qQ>