From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHWse-0000NK-Ia for qemu-devel@nongnu.org; Mon, 18 Mar 2013 06:01:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHWsY-0003XT-9Z for qemu-devel@nongnu.org; Mon, 18 Mar 2013 06:01:24 -0400 Received: from e28smtp04.in.ibm.com ([122.248.162.4]:42081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHWsX-0003Wj-Ko for qemu-devel@nongnu.org; Mon, 18 Mar 2013 06:01:18 -0400 Received: from /spool/local by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 18 Mar 2013 15:27:56 +0530 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id D6803125805C for ; Mon, 18 Mar 2013 15:32:16 +0530 (IST) Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2IA16tQ66322626 for ; Mon, 18 Mar 2013 15:31:07 +0530 Received: from d28av01.in.ibm.com (loopback [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2IA18rZ010356 for ; Mon, 18 Mar 2013 10:01:08 GMT Message-ID: <5146E5C4.4080905@linux.vnet.ibm.com> Date: Mon, 18 Mar 2013 18:00:36 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <50EE33B2.4040504@linux.vnet.ibm.com> <20130110124109.GD30946@stefanha-thinkpad.redhat.com> <50EFAFA4.1030705@linux.vnet.ibm.com> <20130111091253.GA31400@stefanha-thinkpad.muc.redhat.com> <50F373DE.4060709@linux.vnet.ibm.com> <20130114100604.GH11260@stefanha-thinkpad.redhat.com> <50F4FF3C.9000706@linux.vnet.ibm.com> <513EE7B1.6060501@linux.vnet.ibm.com> <20130313101838.GD2309@dhcp-200-207.str.redhat.com> <51415B52.1040409@linux.vnet.ibm.com> <20130314082256.GA2485@dhcp-200-207.str.redhat.com> In-Reply-To: <20130314082256.GA2485@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH V2 07/10] snapshot: qmp use new internal API for external snapshot transaction List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: aliguori@us.ibm.com, quintela@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org, lcapitulino@redhat.com, pbonzini@redhat.com, dietmar@proxmox.com 于 2013-3-14 16:22, Kevin Wolf 写道: > Am 14.03.2013 um 06:08 hat Wenchao Xia geschrieben: >> 于 2013-3-13 18:18, Kevin Wolf 写道: >>> Am 12.03.2013 um 09:30 hat Wenchao Xia geschrieben: >>>> I redesigned the structure, Following is the fake code: >>>> >>>> typedef struct BdrvActionOps { >>>> /* check the request's validation, allocate p_opaque if needed */ >>>> int (*check)(BlockdevAction *action, void **p_opaque, Error **errp); >>>> /* take the action */ >>>> int (*submit)(BlockdevAction *action, void *opaque, Error **errp); >>>> /* update emulator */ >>>> int (*commit)(BlockdevAction *action, void *opaque, Error **errp); >>>> /* cancel the action */ >>>> int (*rollback)(BlockdevAction *action, void *opaque, Error **errp); >>>> } BdrvActionOps; >>> >>> Why do you need the split of prepare into check/submit? >>> >>> If you have prepare/commit/abort, everybody will recognise this as the >>> standard transaction pattern because this is just how it's done. >>> Deviating from it needs a good justification in my opinion. >>> >>> Kevin >>> >> >> My thought is rejecting the request in *check if parameter invalid >> before take any action, while submit do the real action, to reduce >> the chance to of rolling back when some request not valid in the batch. > > Okay, so it's not strictly needed, but an optimisation of the error > case? > > Does it work well when the transaction includes an operation that > depends on the previous one, like create a snapshot and then do > something with this snapshot? > This seems to complex, since prepare of all actions are executed in first round, they may interrupt each other later. So I am thinking make it more clear as complete one job one time, which may change the old qmp_transcation() logic a little. > Anyway, even if we think it works and is worth the effort to optimise > such error cases, please use names that are consistent with the > transactions used for reopening: (check/)prepare/commit/abort. > In above way check/prepare can be merged, how do you think of it? > Kevin > -- Best Regards Wenchao Xia