From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TuaEq-0008SB-Go for qemu-devel@nongnu.org; Sun, 13 Jan 2013 21:57:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TuaEm-0002gj-37 for qemu-devel@nongnu.org; Sun, 13 Jan 2013 21:57:28 -0500 Received: from e28smtp06.in.ibm.com ([122.248.162.6]:56984) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TuaEl-0002g6-7Z for qemu-devel@nongnu.org; Sun, 13 Jan 2013 21:57:24 -0500 Received: from /spool/local by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 14 Jan 2013 08:25:40 +0530 Received: from d28relay02.in.ibm.com (d28relay02.in.ibm.com [9.184.220.59]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id CCBECE004C for ; Mon, 14 Jan 2013 08:27:32 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0E2vChi41222304 for ; Mon, 14 Jan 2013 08:27:13 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0E2vDfP019728 for ; Mon, 14 Jan 2013 13:57:14 +1100 Message-ID: <50F373DE.4060709@linux.vnet.ibm.com> Date: Mon, 14 Jan 2013 10:56:30 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1357543689-11415-1-git-send-email-xiawenc@linux.vnet.ibm.com> <1357543689-11415-9-git-send-email-xiawenc@linux.vnet.ibm.com> <20130109124433.GA391@stefanha-thinkpad.redhat.com> <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> In-Reply-To: <20130111091253.GA31400@stefanha-thinkpad.muc.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: Stefan Hajnoczi Cc: kwolf@redhat.com, aliguori@us.ibm.com, quintela@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, pbonzini@redhat.com, dietmar@proxmox.com 于 2013-1-11 17:12, Stefan Hajnoczi 写道: > On Fri, Jan 11, 2013 at 02:22:28PM +0800, Wenchao Xia wrote: >> 于 2013-1-10 20:41, Stefan Hajnoczi 写道: >>> On Thu, Jan 10, 2013 at 11:21:22AM +0800, Wenchao Xia wrote: >>>> 于 2013-1-9 20:44, Stefan Hajnoczi 写道: >>>>> On Mon, Jan 07, 2013 at 03:28:06PM +0800, Wenchao Xia wrote: >>>>>> This patch switch to internal common API to take group external >>>>>> snapshots from qmp_transaction interface. qmp layer simply does >>>>>> a translation from user input. >>>>>> >>>>>> Signed-off-by: Wenchao Xia >>>>>> --- >>>>>> blockdev.c | 215 ++++++++++++++++++++++++------------------------------------ >>>>>> 1 files changed, 87 insertions(+), 128 deletions(-) >>>>> >>>>> An internal API for snapshots is not necessary. qmp_transaction() is >>>>> already usable both from the monitor and C code. >>>>> >>>>> The QAPI code generator creates structs that can be accessed directly >>>> >from C. qmp_transaction(), BlockdevAction, and BlockdevActionList *is* >>>>> the snapshot API. It just doesn't support internal snapshots yet, which >>>>> is what you are trying to add. >>>>> >>>>> To add internal snapshot support, define a BlockdevInternalSnapshot type >>>>> in qapi-schema.json and add internal snapshot support in >>>>> qmp_transaction(). >>>>> >>>>> qmp_transaction() was designed with this in mind from the beginning and >>>>> dispatches based on BlockdevAction->kind. >>>>> >>>>> The patch series will become much smaller while still adding internal >>>>> snapshot support. >>>>> >>>>> Stefan >>>>> >>>> >>>> As API, qmp_transaction have following disadvantages: >>>> 1) interface is based on string not data type inside qemu, that means >>>> other function calling it result in: bdrv->string->bdrv >>> >>> Use bdrv_get_device_name(). You already need to fill in filename or >>> snapshot name strings. This is not a big disadvantage. >>> >> Yes, not a big disadvantage, but why not save string operation but >> use (bdrv*) as much as possible? >> >> what happens will be: >> >> hmp-snapshot >> | >> qmp-snapshot >> |--------- >> | >> qmp-transaction savevm(may be other..) >> |----------------------| >> | >> internal transaction layer > > Saving the string operation is not worth duplicating the API. > I agree with you for this line:), but, it is a weight on the balance of choice, pls consider it together with issues below. >>>> 2) all capability are forced to be exposed. >>> >>> Is there something you cannot expose? >>> >> As other component in qemu can use it, some option may >> be used only in qemu not to user. For eg, vm-state-size. > > When we hit a limitation of QAPI then it needs to be extended. I'm sure > there's a solution for splitting or hiding parts of the QAPI generated > API. > I can't think it out now, it seems to be a bit tricky. >>>> 3) need structure to record each transaction state, such as >>>> BlkTransactionStates. Extending it is equal to add an internal layer. >>> >>> I agree that extending it is equal coding effort to adding an internal >>> layer because you'll need to refactor qmp_transaction() a bit to really >>> support additional action types. >>> >>> But it's the right thing to do. Don't add unnecessary layers just >>> because writing new code is more fun than extending existing code. >>> >> If this layer is not added but depending only qmp_transaction, there >> will be many "if else" fragment. I have tried that and the code >> is awkful, this layer did not bring extra burden only make what >> happens inside qmp_transaction clearer, I did not add this layer just >> for fun. >> >> >>>> Actually I started up by use qmp_transaction as API, but soon >>>> found that work is almost done around BlkTransactionStates, so >>>> added a layer around it clearly. > > The qmp_transaction() implementation can be changed, I'm not saying you > have to hack in more if statements. It's cleanest to introduce a > BdrvActionOps abstraction: > > typedef struct BdrvActionOps BdrvActionOps; > typedef struct BdrvTransactionState { > const BdrvActionOps *ops; > QLIST_ENTRY(BdrvTransactionState); > } BdrvTransactionState; > > struct BdrvActionOps { > int (*prepare)(BdrvTransactionState *s, ...); > int (*commit)(BdrvTransactionState *s, ...); > int (*rollback)(BdrvTransactionState *s, ...); > }; > > BdrvTransactionState *bdrv_transaction_create(BlockdevAction *action); > > Then qmp_transaction() can be generic code that steps through the > transactions. With internal API, qmp_transaction can still be generic code with a translate from bdrv* to char* at caller level. This is similar to what your series does and I think it's > the right direction. > > But please don't duplicate the qmp_transaction() and > BlockdevAction/BlockdevActionList APIs. In other words, change the > engine, not the whole car. > > Stefan > If my understanding is correct, the BdrvActionOps need to be extended as following: struct BdrvActionOps { /* need following for callback functions */ const char *sn_name; BlockDriverState *bs; ... int (*prepare)(BdrvTransactionState *s, ...); int (*commit)(BdrvTransactionState *s, ...); int (*rollback)(BdrvTransactionState *s, ...); }; Or an opaque* should used for every BdrvActionOps. Comparation: The way above: 1) translate from BlockdevAction to BdrvTransactionState by bdrv_transaction_create(). 2) enqueue BdrvTransactionState by some code. 3) execute them by a new function, name it as BdrvActionOpsRun(). Internal API way: 1) translate BlockdevAction to BlkTransStates by fill_blk_trs(). 2) enqueue BlkTransStates to BlkTransStates by add_transaction(). 3) execute them by submit_transaction(). It seems the way above will end as something like an internal layer, but without clear APIs tips what it is doing. Please reconsider the advantages about a clear internal API layer. -- Best Regards Wenchao Xia