From owner-freebsd-current@FreeBSD.ORG Thu Mar 19 14:01:10 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 2BA2D940; Thu, 19 Mar 2015 14:01:10 +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 F325B60C; Thu, 19 Mar 2015 14:01:09 +0000 (UTC) Received: from new-host-4.home (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 56B92B926; Thu, 19 Mar 2015 10:01:08 -0400 (EDT) Message-ID: <550AD6A3.1020406@FreeBSD.org> Date: Thu, 19 Mar 2015 10:01:07 -0400 From: John Baldwin 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: Julian Elischer , Adrian Chadd Subject: Re: What parts of UMA are part of the stable ABI? References: <2085699.T9kJlc0rkf@ralph.baldwin.cx> <3923303.nkjJO958qy@ralph.baldwin.cx> <550A0B53.9020201@freebsd.org> In-Reply-To: <550A0B53.9020201@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 19 Mar 2015 10:01:08 -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 14:01:10 -0000 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 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. 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