From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKyNu-0006Fk-Ue for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:41:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKyNq-0006Ac-9F for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:41:46 -0400 Received: from [199.232.76.173] (port=38529 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKyNq-0006AN-3E for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:41:42 -0400 Received: from mx2.redhat.com ([66.187.237.31]:41853) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKyNp-0000Py-CK for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:41:41 -0400 Message-ID: <4A47ABAA.5020000@redhat.com> Date: Sun, 28 Jun 2009 20:43:06 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command References: <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> <20090627125833.22d3cc9f@doriath> <4A4791D9.2050400@redhat.com> <5b31733c0906281023n637cd3eax60d14bbe618f63ec@mail.gmail.com> In-Reply-To: <5b31733c0906281023n637cd3eax60d14bbe618f63ec@mail.gmail.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: Filip Navara Cc: Anthony Liguori , ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On 06/28/2009 08:23 PM, Filip Navara wrote: > On Sun, Jun 28, 2009 at 5:52 PM, Avi Kivity wrote: > >> On 06/27/2009 06:58 PM, Luiz Capitulino wrote: >> >>> 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. >>> >>> >> There's no danger of a diverging implementation in this case since no one is >> proposing to have different monitor protocols. We just need to find the >> best protocol. Anthony's looking for minimal churn for the existing monitor >> command set and for libvirt, while I am considering the additional effort >> for new commands and for new clients. >> > > I'm with Avi on this issue, but I will be happy as long as the > protocol is precisely described and extensible for future. Moreover I > believe that converting the current code to use a new function like > monitor_print_data could be done now even without knowing the exact > details of the on-wire protocol. The monitor_print_data function could > be then adjusted to understand the protocol specifics and emit the > data accordingly. > In terms of implementation, I think we could structure the human and machine monitor as follows: - the human monitor parses a command (with the current parser) and generates a dict - the machine monitor (using a json-like parser) parses its input which contains a parameter dict - the dict is handed off to common code - common code does something, returns an error code and a return value - the human monitor prints the return value (with the current printfs) - the machine monitor packs the return value according to the protocol and lets the json-like emitter emit it So we don't have to duplicate parsers an emitters; instead we have to write some accessor functions for generalized values (which can come from the human monitor, command line, machine monitor, and maybe config file). -- error compiling committee.c: too many arguments to function