From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKaIh-00070o-BU for qemu-devel@nongnu.org; Sat, 27 Jun 2009 11:58:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKaIc-0006v0-Tz for qemu-devel@nongnu.org; Sat, 27 Jun 2009 11:58:46 -0400 Received: from [199.232.76.173] (port=42087 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKaIc-0006ut-Nq for qemu-devel@nongnu.org; Sat, 27 Jun 2009 11:58:42 -0400 Received: from mx2.redhat.com ([66.187.237.31]:32903) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKaIc-0004K1-5d for qemu-devel@nongnu.org; Sat, 27 Jun 2009 11:58:42 -0400 Date: Sat, 27 Jun 2009 12:58:33 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command Message-ID: <20090627125833.22d3cc9f@doriath> In-Reply-To: <20090626094224.GE28206@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> <20090625161143.01b56eea@doriath> <4A4492FD.4040704@redhat.com> <20090626094224.GE28206@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: "Daniel P. Berrange" Cc: Anthony Liguori , ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Avi Kivity On Fri, 26 Jun 2009 10:42:24 +0100 "Daniel P. Berrange" wrote: > On Fri, Jun 26, 2009 at 12:21:01PM +0300, Avi Kivity wrote: > > On 06/25/2009 10:11 PM, Luiz Capitulino wrote: > > > > > > 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? > > > > > The sane way is to *NOT* break ABI of libmonitor.so, and not change > the wire protocol in a non backwards compatible way. This is entirely > doable, it just the maintainer of libmonitor/qemu to decide that ABI > stability is important. So if you find an existing API / command > needs to gain an extra argument, you don't change the existing API, > you add a new one. Or ideally design the API upfront so that it > can be extended without breaking back compatability. [ Looks like my (evil) twin brother has taken the keyboard while I was away and has started saying libmonitor.so non-sense. ] I think I have mixed up problems here, but anyway, working on a C library seems a step back to me. I believe that defining the API for it will generate more discussion than the protocol, will probably be harder to write and to document too. In a general way the protocol idea is very simple: we just have to make monitor's output parsable. As Anthony has put it, the patchset is not far from a mergeable state. I can't even image how long it would take to have the C API in the same shape. That said, I think the protocol discussion went way too far. Of course that I want to do the right thing and we should always be concerned with the future, but the priority here is not to design/choose the next-ultra-super-hiper-mathematically-proven-and-loved protocol. So, IMHO both solutions (QMP and JSON) solves the problem and I would work on either one. I just would like that Anthony and Avi get in agreement, because the project will fail if it becomes one more difference between qemu and qemu-kvm.