From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 15:59:57 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0B29DCD for ; Wed, 18 Mar 2015 15:59:57 +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 C6FCFED0 for ; Wed, 18 Mar 2015 15:59:57 +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 78C32B93A; Wed, 18 Mar 2015 11:59:56 -0400 (EDT) From: John Baldwin To: Ryan Stone Subject: Re: What parts of UMA are part of the stable ABI? Date: Wed, 18 Mar 2015 11:23:15 -0400 Message-ID: <3923303.nkjJO958qy@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <2085699.T9kJlc0rkf@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); Wed, 18 Mar 2015 11:59:56 -0400 (EDT) Cc: FreeBSD Current 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: Wed, 18 Mar 2015 15:59:58 -0000 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). -- John Baldwin