From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJZnD-00034j-Sm for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:14:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJZn9-00031v-1U for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:14:07 -0400 Received: from [199.232.76.173] (port=35316 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJZn8-00031o-PX for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:14:02 -0400 Received: from mail2.shareable.org ([80.68.89.115]:56323) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJZn7-0002Pf-KJ for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:14:01 -0400 Date: Wed, 24 Jun 2009 22:13:58 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090624211358.GA14121@shareable.org> References: <4A412339.5000109@redhat.com> <4A412659.1080803@us.ibm.com> <20090623220204.GA5612@snarc.org> <4A415C30.7030301@us.ibm.com> <20090624010108.GA6537@snarc.org> <4A42200C.6060600@codemonkey.ws> <5b31733c0906240857g546316e0pd92fee9afe6115fa@mail.gmail.com> <4A4252DD.70300@redhat.com> <20090624190539.GR14121@shareable.org> <5b31733c0906241224j50baa7e6lc80b8c79c5d6baa7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5b31733c0906241224j50baa7e6lc80b8c79c5d6baa7@mail.gmail.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Filip Navara Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity , Vincent Hanquez Filip Navara wrote: > > QEMU's monitor is already much easier to use than that. > > For human? Definitely! For shell scripts? Yes. For libraries that need > to parse the data reliably? No. Yes, it could do with a more well-defined formatting. Documented escaping of unusual characters in names would be a start :-) > > When a new monitor command is added, you can use it from scripts as > > trivial one-liner text commands, assuming you already have a way to > > connect to the monitor. > > Since when was calling from scripts added as requirement? Don't get me > wrong, I would be happy to cover this use case as well. It's a diverse > use case from the libvirt usage though, in my humble opinion. Aren't most QEMU management programs (other than libvirt) scripts? Looks to me like "works with libvirt and other management programs" implies that you can use it from scripts, because many management programs are, in fact, scripts. If the requirement is simply "works with libvirt", then closer integration with libvirt would be better than trying to cleanly RPC everything. After all, libvirt already has it's own RPC layer for everything connecting to it, and libvirt people want all QEMU interaction to happen via libvirt anyway. There's no point having multiple different RPC layers carrying exactly the same commands in different ways. -- Jamie