qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file


From: Filip Navara
Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file
Date: Wed, 24 Jun 2009 21:24:23 +0200

On Wed, Jun 24, 2009 at 9:05 PM, Jamie Lokier<address@hidden> 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.  It may have been
>> due to implementation details, not to the spec itself, but it definitely
>> left a bad taste in my mouth.  Also, I don't see a SunRPC implementation
>> for Python, which (along with similar languages) is an ideal platform
>> for controlling qemu.  I'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.  Hiding 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]