From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJY58-0008Fi-BU for qemu-devel@nongnu.org; Wed, 24 Jun 2009 15:24:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJY53-0008EB-QP for qemu-devel@nongnu.org; Wed, 24 Jun 2009 15:24:30 -0400 Received: from [199.232.76.173] (port=43981 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJY53-0008E3-Ha for qemu-devel@nongnu.org; Wed, 24 Jun 2009 15:24:25 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]:51832) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJY53-0000TY-1K for qemu-devel@nongnu.org; Wed, 24 Jun 2009 15:24:25 -0400 Received: by ewy7 with SMTP id 7so1412171ewy.34 for ; Wed, 24 Jun 2009 12:24:24 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20090624190539.GR14121@shareable.org> References: <4A40FFB0.2070905@redhat.com> <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> Date: Wed, 24 Jun 2009 21:24:23 +0200 Message-ID: <5b31733c0906241224j50baa7e6lc80b8c79c5d6baa7@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file From: Filip Navara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity , Vincent Hanquez On Wed, Jun 24, 2009 at 9:05 PM, Jamie Lokier wrote: > Avi Kivity wrote: >> On 06/24/2009 06:57 PM, Filip Navara wrote: >> >Given the fact that we practically have the library for XDR it would >> >be very easy to build Sun RPC server on top of it. So my vote is for >> >SunRPC. >> > >> >> My experience with SunRPC (NFS) has been pretty bad. =A0It may have been >> due to implementation details, not to the spec itself, but it definitely >> left a bad taste in my mouth. =A0Also, I don't see a SunRPC implementati= on >> for Python, which (along with similar languages) is an ideal platform >> for controlling qemu. =A0I'd rather have something more modern. > > SunRPC works, and it's fine if you always access it through utilities, > like say a C command-line client. =A0Hiding the SunRPC aspect :-) > > It's pretty fast too, so good for things like network filesystems. > > But it's a real pain to use from scripts if you don't have a pre-built > utility which implements all application RPC functions already. True. Text-based RPCs as JSON-RPC and XML-RPC are half as painful, but still painful. > The basic problem is needing to create and compile C code - for all > clients as well as the server - each time an RPC function is added or > changed. You don't need rebuild the client if the server interface stays compatible and if you don't need the new functionality. Also my initial idea was to use QEMU functions for building the XDR binary payloads inside QEMU. Not sure if it's good idea, but it would work and it's easy to implement for the proposed monitor_print_data function. > 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. > 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. I'd prefer killing one bird to knocking two of them and leaving them half-dead. Best regards, Filip Navara