From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJB1m-0002Gt-1x for qemu-devel@nongnu.org; Tue, 23 Jun 2009 14:47:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJB1h-00029Y-Dx for qemu-devel@nongnu.org; Tue, 23 Jun 2009 14:47:29 -0400 Received: from [199.232.76.173] (port=51822 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJB1h-00029L-1v for qemu-devel@nongnu.org; Tue, 23 Jun 2009 14:47:25 -0400 Received: from mx2.redhat.com ([66.187.237.31]:51776) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJB1g-0001Cg-Fj for qemu-devel@nongnu.org; Tue, 23 Jun 2009 14:47:24 -0400 Message-ID: <4A412339.5000109@redhat.com> Date: Tue, 23 Jun 2009 21:47:21 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file References: <20090623012811.53a62493@doriath> <20090623144521.GA614@snarc.org> <4A40FB11.8090100@redhat.com> <4A40FB26.2040702@us.ibm.com> <4A40FD1A.1040303@redhat.com> <4A40FE31.2010007@us.ibm.com> <4A40FFB0.2070905@redhat.com> <4A411FC5.7050701@us.ibm.com> In-Reply-To: <4A411FC5.7050701@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Vincent Hanquez On 06/23/2009 09:32 PM, Anthony Liguori wrote: > Avi Kivity wrote: >> >> An RPC makes it a lot easier for clients to parse, there's no need >> for a regular expression per command, or to bother with line >> continuations etc. You just focus on the data. >> >> We have an opportunity to make a clean break, let's make use of it. > > If we structure things internally correctly, by having a flow that > basically looks like: > > int (Monitor *mon, ) > { > // process args > if (success) { > monitor_print_data(mon, ); > } else { > record_extended_error(); > return error_code; > } > } > > Then it that works well for both the human monitor and the computer > monitor. It's an RPC though. It looks brittle to me. What if you want to add an array? Some structure that contains a nested structure? > Should we support other types of RPCs? I don't know. I'd think that > you could create a computer monitor -> jsonrpc bridge easily enough. No doubt, but I look at jsonrpc as a way of reducing the effort in qemu. Not so much interested in it for its own sake. > If we implement this correctly, then an RPC interface could just be > another option to see the computer monitor mode implemented as a > "module". This is deep into overkill territory IMO. We should pick some format that is good enough and has implementations for a variety of languages. Luiz' RFC was well done, but the subject is complex enough to be difficult to get right. And as far as I could tell, all the issues are addressed by jsonrpc. The only downside I can see is that jsonrpc is some kind of ajax-kiddie web-2.0 script dom thingie while we are a serious UNIX style daemon that complies with RFC 123456. >>> I don't want to invent Xen-API here and go through that pain in QEMU. >> >> I don't see the parallel. > > Xen-API was the "clean break" for Xend. > Anything can be screwed up. Normally I'm very much against rewrites and totally for incremental progress, but when it comes to protocols, you have to get them right first shot. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.