From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53209)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mreitz@redhat.com>) id 1XsqEm-0002sV-6J
	for qemu-devel@nongnu.org; Mon, 24 Nov 2014 04:47:22 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mreitz@redhat.com>) id 1XsqEf-0001BJ-S8
	for qemu-devel@nongnu.org; Mon, 24 Nov 2014 04:47:16 -0500
Received: from mx1.redhat.com ([209.132.183.28]:39979)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mreitz@redhat.com>) id 1XsqEf-0001Ax-JQ
	for qemu-devel@nongnu.org; Mon, 24 Nov 2014 04:47:09 -0500
Message-ID: <5472FE91.7000402@redhat.com>
Date: Mon, 24 Nov 2014 10:46:57 +0100
From: Max Reitz <mreitz@redhat.com>
MIME-Version: 1.0
References: <1414639364-4499-1-git-send-email-famz@redhat.com>	<1414639364-4499-9-git-send-email-famz@redhat.com>
	<5458B279.8010300@redhat.com> <546FBB93.7000809@redhat.com>
	<5472EDE4.6050509@redhat.com> <5472FD4F.2090301@redhat.com>
In-Reply-To: <5472FD4F.2090301@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v6 08/10] qapi: Add transaction support to
 block-dirty-bitmap-{add, enable, disable}
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>, John Snow <jsnow@redhat.com>, Fam Zheng <famz@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Benoit Canet <benoit@irqsave.net>, Markus Armbruster <armbru@redhat.com>, Luiz Capitulino <lcapitulino@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, Jd <jd_jedi@convirture.com>, Vladimir Sementsov-Ogievskij <etendren@gmail.com>

On 2014-11-24 at 10:41, Paolo Bonzini wrote:
>
> On 24/11/2014 09:35, Max Reitz wrote:
>>>> But what if the dirty bitmap was enabled before so that this enabling
>>>> transaction was supposed to be a no-op?
>>> Maybe it's not a problem: The only case in which the enable/disable
>>> operation will fail is if it cannot find the device or bitmap -- in
>>> which case, the abort operation isn't going to be able to affect
>>> anything either.
>> Well, it's part of a transaction. As far as I understand it, one groups
>> several operations in one transaction and if any fails, all are aborted.
>> Therefore, the "enable the dirty bitmap" operation can trivially succeed
>> (because it was enabled before), but some different operation may fail,
>> which then results in invocation of this abort function.
> Would it work to do the actual enabling/disabling in the commit
> function, since it cannot fail?

Too easy. :-)

This patch could then no longer reuse qmp_block_dirty_bitmap_enable(), 
but reimplementing it here should be fine (it's short enough).

Max