From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53605) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYDdV-0002re-38 for qemu-devel@nongnu.org; Wed, 18 Mar 2015 09:03:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYDdQ-0003vJ-CB for qemu-devel@nongnu.org; Wed, 18 Mar 2015 09:03:49 -0400 Message-ID: <550977AD.6080309@redhat.com> Date: Wed, 18 Mar 2015 09:03:41 -0400 From: Max Reitz MIME-Version: 1.0 References: <1425528911-10300-1-git-send-email-jsnow@redhat.com> <1425528911-10300-6-git-send-email-jsnow@redhat.com> <55087624.5040601@redhat.com> <5508AED0.1010702@redhat.com> In-Reply-To: <5508AED0.1010702@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 05/11] block: add delayed bitmap successor cleanup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , qemu-block@nongnu.org Cc: kwolf@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, vsementsov@parallels.com, stefanha@redhat.com On 2015-03-17 at 18:46, John Snow wrote: > > > On 03/17/2015 02:44 PM, Max Reitz wrote: >> On 2015-03-04 at 23:15, John Snow wrote: [snip] >>> + } >>> +} >>> + >>> +BdrvDirtyBitmap *bdrv_dirty_bitmap_decref(BlockDriverState *bs, >> >> I don't know whether I'm that content with the name chosen, because >> you're actually decrementing the refcount of the successor; but since >> the successor is basically a clone of the original bitmap (and I mean in >> the Star Trek sense, that it's a teleported clone and the original is >> intended to be destroyed so the successor can replace it), decrementing >> the refcount of the successor basically is equal to decrementing the >> refcount of the bitmap itself (as long as there is a successor, which >> you are asserting; maybe you want to add a comment about that to >> include/block/block.h, that one can only use this on frozen bitmaps?). >> > > I could get clever with the name and call it > bdrv_frozen_bitmap_decref, which hopefully still shows membership to > the bdrv_dirty_bitmap class of functions but clarifies its usage > sufficiently. Sounds good to me. [snip] >>> diff --git a/block/backup.c b/block/backup.c >>> index 41bd9af..4332df4 100644 >>> --- a/block/backup.c >>> +++ b/block/backup.c >>> @@ -240,6 +240,12 @@ static void backup_complete(BlockJob *job, void >>> *opaque) >>> bdrv_unref(s->target); >>> + if (s->sync_bitmap) { >>> + BdrvDirtyBitmap *bm; >>> + bm = bdrv_dirty_bitmap_decref(job->bs, s->sync_bitmap, >>> data->ret, NULL); >>> + assert(bm); >> >> You can use &error_abort as the Error object and drop the assert(); or, >> if you are dropping the Error parameter, there is no need to check the >> return value at all, because it will always be non-NULL (there won't be >> any code path in the function returning NULL at all). Maybe you can even >> drop the return value, too. >> >> I just looked through the series: Actually, you're never using the Error >> parameter for bdrv_dirty_bitmap_decref() at all. Seems to me like you >> really should drop it (and maybe the return value along with it). >> > > I actually use this parameter to return the "new bitmap" (if any) > after the decrement operation. I wanted to leave the window open for > merge optimizations, so I tell the caller which bitmap remains after > the operation. > > I will cull the errp, but will likely leave the return code. OK. Max