From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKxGr-0007CK-69 for qemu-devel@nongnu.org; Sun, 28 Jun 2009 12:30:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKxGq-0007AI-73 for qemu-devel@nongnu.org; Sun, 28 Jun 2009 12:30:24 -0400 Received: from [199.232.76.173] (port=50080 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKxGq-00079k-1Y for qemu-devel@nongnu.org; Sun, 28 Jun 2009 12:30:24 -0400 Received: from fg-out-1718.google.com ([72.14.220.158]:8595) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKxGp-0000Qv-H8 for qemu-devel@nongnu.org; Sun, 28 Jun 2009 12:30:23 -0400 Received: by fg-out-1718.google.com with SMTP id l27so316969fgb.8 for ; Sun, 28 Jun 2009 09:30:22 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4A4791D9.2050400@redhat.com> 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> Date: Sun, 28 Jun 2009 19:30:21 +0300 Message-ID: Subject: Re: [Qemu-devel] Re: [PATCH 08/11] QMP: Port balloon command From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On 6/28/09, 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. It really isn't very complicated, and > the thread only got so long because the topic is relatively simple. Post an > RFC and a mile-long patchset about changing TCG to SSA form, and see how you > get no replies. No, I think the trick is to have the mile-long patchset that twiddles something in the block layer. It can potentially cause deadly bugs for every guest and the benefit may not be obvious.