From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJtj5-0003kW-0O for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:31:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJtiz-0003jX-5P for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:31:09 -0400 Received: from [199.232.76.173] (port=52600 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJtiz-0003jU-0P for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:31:05 -0400 Received: from mx2.redhat.com ([66.187.237.31]:49287) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJtiy-0000UM-GY for qemu-devel@nongnu.org; Thu, 25 Jun 2009 14:31:04 -0400 Message-ID: <4A43C264.6060803@redhat.com> Date: Thu, 25 Jun 2009 21:31:00 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file References: <4A412339.5000109@redhat.com> <4A412659.1080803@us.ibm.com> <20090623220204.GA5612@snarc.org> <4A415C30.7030301@us.ibm.com> <20090624010108.GA6537@snarc.org> <4A42200C.6060600@codemonkey.ws> <5b31733c0906240857g546316e0pd92fee9afe6115fa@mail.gmail.com> <4A4252DD.70300@redhat.com> <20090624190539.GR14121@shareable.org> <5b31733c0906241224j50baa7e6lc80b8c79c5d6baa7@mail.gmail.com> <20090624211358.GA14121@shareable.org> <4A43768A.2090604@eu.citrix.com> <4A438FDD.5060206@redhat.com> <4A43935D.6000506@codemonkey.ws> <4A4395B8.4010401@redhat.com> <4A43BD5D.80307@codemonkey.ws> In-Reply-To: <4A43BD5D.80307@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; 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" , Stefano Stabellini , "jan.kiszka@siemens.com" , "dlaor@redhat.com" , "qemu-devel@nongnu.org" , Luiz Capitulino , Filip Navara , Vincent Hanquez On 06/25/2009 09:09 PM, Anthony Liguori wrote: > Avi Kivity wrote: >>> An RPC is overkill unless you also introduce things like life cycle >>> management. Otherwise, you could never realistically interact with >>> QEMU without a intermediary that handled life cycle management (e.g. >>> libvirt). >> >> QMP is an RPC implemented over a text based protocol, with ad-hoc >> marshalling. >> >> I agree that you need something to reap dead qemus, but I don't think >> we can force libvirt on people. > > QMP is an incremental improvement to the current monitor which people > are consuming today. It will have a pretty immediate and high rate of > return. libvirt can make use of it with probably very little change > and it will immediately provide them with new features (async > notifications) and better information about commands (error return > values). > The incremental cost of porting a monitor command, documenting its format, improving QMP infrastructure where necessary, and implementing that command across all clients is much greater than RPC. For a new client implemented in a high level language, using QMP will be substantially more difficult than using RPC, and the probability of getting things right will be much greater. Targeting libvirt alone is a mistake. Of course libvirt is a very important user of the qemu monitor, but not doing the right thing because libvirt has some prior art is shortsighted IMO. RPC offers the best choice for growth, in adding new commands, and in supporting more clients. > I have a really hard time not thinking this is the right thing to do > because for relatively little churn we'll get a large return. If you > just exposed the monitor as an RPC, I don't think you really get > anything more useful than QMP and you force a lot more change in > libvirt which hurt the adoption of this protocol. Adopting an RPC should be easier than adopting QMP, since all you have to do is compile the IDL. Again I point to the incremental cost of adding a command. > This is exactly what happened with Xend's transition from SExpr/HTTP > (custom RPC) -> XML-RPC -> XenAPI. libvirt still uses SExpr/HTTP > because the cost of switching to the new way of doing things didn't > warrant the return on investment. I think this points to libvirt doing something wrong. I suspect it's the implementation language. > s/libvirt/any other management tool that works today/g Anything written in a high level language (say, Python) will be trivial to port to an RPC. RPC clients in Python can be typed in with one finger in a couple of minutes. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.