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 23:29:38 +0200

On Wed, Jun 24, 2009 at 11:13 PM, Jamie Lokier<address@hidden> wrote:
> 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?

I don't feel competent to answer that.

> 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 that was true then certainly a text/line-based protocol would make
sense (possibly in addition to a simple RPC one, if desired). The
thing I am worried about is that several corner cases are currently
not defined in the proposed protocol and it introduces asynchronous
events, which is actually harder to get right in shell scripts than
the human protocol.

> 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
>

Best regards,
Filip Navara




reply via email to

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