From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3SAq-0001d9-HN for qemu-devel@nongnu.org; Fri, 02 Mar 2012 08:05:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3SAj-0005Ag-Lq for qemu-devel@nongnu.org; Fri, 02 Mar 2012 08:05:28 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:49027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3SAj-0005AS-Fk for qemu-devel@nongnu.org; Fri, 02 Mar 2012 08:05:21 -0500 Received: by pbcuo5 with SMTP id uo5so1153258pbc.4 for ; Fri, 02 Mar 2012 05:05:19 -0800 (PST) Message-ID: <4F50C58B.4020606@codemonkey.ws> Date: Fri, 02 Mar 2012 07:05:15 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1330600908-16202-1-git-send-email-pbonzini@redhat.com> <4F4FE5B7.2080306@codemonkey.ws> <4F4FEA65.2080903@redhat.com> <4F4FEBCB.7020509@codemonkey.ws> In-Reply-To: <4F4FEBCB.7020509@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 0/6] Mirrored writes using blockdev-transaction List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, stefanha@linux.vnet.ibm.com, jcody@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, fsimonce@redhat.com, Paolo Bonzini On 03/01/2012 03:36 PM, Anthony Liguori wrote: > On 03/01/2012 03:30 PM, Eric Blake wrote: >> On 03/01/2012 02:10 PM, Anthony Liguori wrote: >>>> 2) Execute the following QMP command >>>> >>>> { "execute": "qmp_capabilities" } >>>> { "execute": "blockdev-transaction", "arguments": >>>> {'actions': [ >>>> { 'type': 'snapshot', 'data' : >>>> { 'device': 'ide0-hd0', 'snapshot-file': >>>> '/home/pbonzini/base.qcow2' } }, >>>> { 'type': 'mirror', 'data' : >>>> { 'device': 'ide0-hd0', 'target': '/home/pbonzini/mirror.qcow2' >>>> } } ] } } >>>> { "execute": "cont" } >>> >>> We don't have schema introspection today. How would one determine when >>> new transaction types are available? >>> >>> I think we need some sort of introspection method too in order for >>> clients to figure out when the command is extended. >>> >> >> I agree that introspection is necessary. Up till now, libvirt could get >> by with query-commands (either a command exists or it doesn't). But now >> we have the case where blockdev-transaction might exist, but doesn't >> support the particular union action such as 'mirror' that libvirt wants >> to use. >> >> Could this be something we wire up to the query-commands command? >> >> Something like: >> >> { 'type': 'CommandInfo', 'data': {'name': 'str', '*syntax': 'str'} } >> { 'command': 'query-commands, >> 'data': { '*syntax': 'bool', '*names': ['str'] }, >> 'returns': ['CommandInfo'] } >> >> where the normal {"execute":"qemu-commands"} just returns the list of >> command names, but {"execute":"qemu-commands", "arguments": { "syntax": >> "true", "names" : [ "blockdev-transaction" ] } } then returns: >> >> {"return":[{"name":"blockdev-transaction", "syntax":"{ 'command' ... >> }"}], "id":"..."} >> >> that is, return back the qapi-schema.json description of the command. >> Actually, I'd guess you'd also want to be able to query 'type' listings, >> not just 'command's, so maybe this deserves a new monitor command rather >> than shoe-horning it onto an existing one. > > Yes, this is what I would like to do, but it's a requires a bit of work to > implement. You'd have to either install qapi-schema.json and read it at run time > or serialize it to a C data structure that can then be used to initialize a > QObject. > > Nothing Earth shattering, just a fair amount of bit moving. BTW, in the short term, this can be addressed with careful documentation. Just make it clear that in the absence of introspection, the only two supported operations are what's currently here. And realize that to add new commands in the future, we need introspection first. Regards, Anthony Liguori > > Regards, > > Anthony Liguori > >> > >