From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJuMf-0001SH-GM for qemu-devel@nongnu.org; Thu, 25 Jun 2009 15:12:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJuMb-0001NJ-08 for qemu-devel@nongnu.org; Thu, 25 Jun 2009 15:12:05 -0400 Received: from [199.232.76.173] (port=55311 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJuMa-0001N9-T1 for qemu-devel@nongnu.org; Thu, 25 Jun 2009 15:12:00 -0400 Received: from mx2.redhat.com ([66.187.237.31]:39690) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJuMa-0002SN-Em for qemu-devel@nongnu.org; Thu, 25 Jun 2009 15:12:00 -0400 Date: Thu, 25 Jun 2009 16:11:43 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command Message-ID: <20090625161143.01b56eea@doriath> In-Reply-To: <4A435F09.7050702@redhat.com> References: <20090623012933.5b217767@doriath> <4A40A386.7020102@redhat.com> <4A40DFCE.5050008@codemonkey.ws> <20090623135958.660903e1@doriath> <4A412135.2060804@us.ibm.com> <4A435F09.7050702@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: Anthony Liguori , ehabkost@redhat.com, jan.kiszka@siemens.com, qemu-devel@nongnu.org, Avi Kivity On Thu, 25 Jun 2009 14:27:05 +0300 Dor Laor wrote: > On 06/23/2009 09:38 PM, Anthony Liguori wrote: > > > > I wanted to respond to the top level, but here's what I see as the > > potential merge plan: > > > > 1) Make all commands return a value > > 2) Add a mechanism to mark commands as being "structured" > > This seems like a good idea. > My original intent was to make the monitor interface a library. > Various qemu users can link it with their favorite option: > json/dbus/rpm/xml/soap ;) Yes, having a library was suggested by Amit some months ago. The problem is that it has various issues wrt maintainability. For example, libvirt is able to run two instances of different versions of qemu at the same time. How to handle this if you update libmonitor.so? I think people have agreed that having a protocol is good here, but as Anthonhy puts it we need: 1. Choose between QMP and some kind of RPC 2. If RPC is choosen, what kind of RPC to use > So, we should first harden up the monitor commands like 1),2), and > refactor the current > monitor interface as a library above it. If I'm not mistaken, "structured" commands only makes sense with QMP. The plan will be different if we choose RPC. > > 3) Get the structured printfs in order. > > 4) Merge > > > > I won't want QMP to be exposed as a usable interface until all > > commands are converted. This means holding off on the last patch I > > think. I don't think we'll get QMP for 0.11. I think it's likely > > going to be a 0.12 feature. However, I'd like to start merging this > > series as soon as humanly possible. I think it's already pretty close. > > > If we push 'monitor standardization' into 0.11, the version will support > future > implementations of the protocol. > > Regards, > Dor