From owner-freebsd-current@FreeBSD.ORG Wed Mar 18 23:33:50 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 E64EF2C0; Wed, 18 Mar 2015 23:33:50 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A50BE14; Wed, 18 Mar 2015 23:33:50 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-255-201.lns20.per4.internode.on.net [121.45.255.201]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t2INXj7p049235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 Mar 2015 16:33:48 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <550A0B53.9020201@freebsd.org> Date: Thu, 19 Mar 2015 07:33:39 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Adrian Chadd , John Baldwin Subject: Re: What parts of UMA are part of the stable ABI? References: <2085699.T9kJlc0rkf@ralph.baldwin.cx> <3923303.nkjJO958qy@ralph.baldwin.cx> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 18 Mar 2015 23:33:51 -0000 On 3/19/15 3:28 AM, 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 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. > > > > -adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >