From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJAtS-0006lp-SO for qemu-devel@nongnu.org; Tue, 23 Jun 2009 14:38:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJAtP-0006fC-07 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 14:38:54 -0400 Received: from [199.232.76.173] (port=40681 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJAtO-0006en-CF for qemu-devel@nongnu.org; Tue, 23 Jun 2009 14:38:50 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:36163) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJAtN-0006Rj-PL for qemu-devel@nongnu.org; Tue, 23 Jun 2009 14:38:50 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e38.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5NIZgi8023703 for ; Tue, 23 Jun 2009 12:35:42 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5NIclOW150530 for ; Tue, 23 Jun 2009 12:38:47 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5NIcl1X010054 for ; Tue, 23 Jun 2009 12:38:47 -0600 Message-ID: <4A412135.2060804@us.ibm.com> Date: Tue, 23 Jun 2009 13:38:45 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command References: <20090623012933.5b217767@doriath> <4A40A386.7020102@redhat.com> <4A40DFCE.5050008@codemonkey.ws> <20090623135958.660903e1@doriath> In-Reply-To: <20090623135958.660903e1@doriath> 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: Luiz Capitulino Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Avi Kivity Luiz Capitulino wrote: > On Tue, 23 Jun 2009 08:59:42 -0500 > Anthony Liguori wrote: > > >> How this gets output can then be conditional on control mode vs. human >> mode. In human mode, we can use human-friendly units like MBs. In >> control mode, we would always use bytes. >> > > For me, this is one of the hardest aspects of the project. > > It is more general than unit conversion, the problem is: how should > commands output (specially multline) look like? > > I have talked with Eduardo about this, and I have chosen the simplest > approach, which is prefixing commands output by '='. That is, the > protocol doesn't change commands output, just adds prefixes. > I'm not saying you should change command output. Most commands follow a similar format quite intentionally. That's:
: =[,=[...]] I'm just suggesting that you codify that instead of leaving it open coded everywhere. Nothing more than that. > This approach has the advantage of making the protocol merge very > easy and I believe it will be less painful to maintain as well. > FWIW, you could introduce monitor_printf_list() as your first patch. >>> We also need a way to discover that the command is available: >>> >> I think we want to version each command too. >> > > making it quite complicated. :) > > If we go this way (of defining an output for each command or even > defining a version for each command) I fear we will take forever > to get in agreement and merge the whole series. > > Another related question is: should we port 100% of the command > set up front or can we merge small sets, defining a new version of > the protocol each time? > > What I would like to do for QMP V1 is: > > 1. Keep what this series is doing, that is, keep commands output > unchanged and only add prefixes (unit conversion is ok though) > > 2. Define a set of commands to be part of V1, and port them > > We can try to port the whole set as fast as we can (say, until > V3). Right after that, we could start improving commands output. > 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" 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. -- Regards, Anthony Liguori