From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:52065)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Xsq9e-00051n-Fn
	for qemu-devel@nongnu.org; Mon, 24 Nov 2014 04:42:04 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Xsq9Y-0007NE-6d
	for qemu-devel@nongnu.org; Mon, 24 Nov 2014 04:41:58 -0500
Received: from mx1.redhat.com ([209.132.183.28]:38348)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1Xsq9X-0007Mw-Uo
	for qemu-devel@nongnu.org; Mon, 24 Nov 2014 04:41:52 -0500
Message-ID: <5472FD4F.2090301@redhat.com>
Date: Mon, 24 Nov 2014 10:41:35 +0100
From: Paolo Bonzini <pbonzini@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>
In-Reply-To: <5472EDE4.6050509@redhat.com>
Content-Type: text/plain; charset=utf-8
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: Max Reitz <mreitz@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 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?

Paolo