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: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file
Date: Fri, 26 Jun 2009 12:16:38 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2

On 06/26/2009 12:10 PM, Daniel P. Berrange wrote:

Let's turn this around.  IIRC libvirt uses an RPC interface for its
clients.  How would you estimate the effort to port this interface to
QMP, and adapt all its clients?

The libvirt RPC interface is a binary message based protocol, using XDR
to encode arguments/return values, and emit signals. The libvirt for
handling this is quite complex because it has to deal with TLS, and
SASL for data encryption, as well as alllowing overlapping RPC requests
on a single TCP connection ( to allow multi-threaded clients to have
parallelized method calls without opening multiple connections). So
it would be a fairly significant amount of work, in comparison to the
current QMP proposal.

You're describing an RPC with asynchronous commands and notifications, with support for authentication and authorization. While qemu doesn't need auth*, it does need the other features, so RPC looks like a good fit.

The existing libvirt code to talk to QEMU's monitor is actually rather
simple by comparison to our native RPC code. The problems we have
historically had with the QEMU monitor were, ill defined data printed
when an error occurs,  the changing of monitor commands between QEMU
releases in incompatible ways, the lack of quoting for arguments and
no support for async events.

No doubt RPC is complicated if you implement it yourself, but surely you used a library? Actually using the RPC is simpler than a line protocol.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.





reply via email to

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