From owner-freebsd-current@FreeBSD.ORG Thu Mar 19 11:31:06 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F4DDB9; Thu, 19 Mar 2015 11:31:06 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 654DD1B7; Thu, 19 Mar 2015 11:31:06 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4BC90B945; Thu, 19 Mar 2015 07:31:04 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: What parts of UMA are part of the stable ABI? Date: Wed, 18 Mar 2015 18:16:21 -0400 Message-ID: <5300497.pLlpQqgG2T@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <3923303.nkjJO958qy@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 19 Mar 2015 07:31:04 -0400 (EDT) Cc: FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 11:31:06 -0000 On Wednesday, March 18, 2015 12:28:07 PM Adrian Chadd wrote: > On 18 March 2015 at 08:23, John Baldwin wrote: > > On Wednesday, March 18, 2015 11:19:21 AM Ryan Stone wrote: > >> On Wed, Mar 18, 2015 at 10:24 AM, John Baldwin 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 think that's a bit too cavalier. Just because it fixes a bug doesn't mean we don't care about the ABI implications in general. (That is, I think your blanket implication that it's ok to break the kernel ABI at anytime if the change fixes a bug is wrong.) It is possible to fix bugs while preserving the ABI, it just requires more work. Our ABI constraints are not just for userland, we do also try to preserve the ABI of a subset of kernel symbols as well (mostly those used by device drivers). The stickler though is which symbols fall into that category since the line for the kernel is much fuzzier than for userland. In general I would err on the side of caution and provide shims if they are feasible. I do think that the uma_alloc case is obscure enough to not be one we care about for ABI compat. I couldn't find the bpf example I was thinking of earlier, but this commit includes the shim method I described previously to preserve the ABI for old modules while fixing the API for new ones (and this was to fix a bug): https://svnweb.freebsd.org/base?view=revision&revision=196006 -- John Baldwin