[Top][All Lists]

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

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

From: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH 01/11] QMP: Introduce specification file
Date: Tue, 23 Jun 2009 13:08:00 +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 Lightning/1.0pre Thunderbird/3.0b2

On 06/23/2009 12:57 PM, Daniel P. Berrange wrote:
Maybe add a numeric error code (to be defined by individual commands).

I think that would be particularly useful to allow clients to distinguish
the error from a command which does not exist, vs a command that exists
but failed. There's probably a handful of common errors that you want
to detect from all commands with the same error handling logic.

There should be mechanisms to detect which commands are available. Not all commands will have fallbacks, so the user might want to query which commands (or features) exist before actually launching the guest.

The guest reboots (actually, resets), not qemu.  And 'info balloon' will
eventually print its response, no?

Might we need to have timestamp assoicated with each response, or will we
define that responses are explicitly ordered wrt events,to reflect the order
in which they're handled. eg When the 'info balloon' response arrives, we
want to know whether the data it contains is reflecting state before or
after the reboot.

Responses are implicitly ordered. But a timestamp for events might be good for other reasons (when the event happened vs. when management got around to processing it; might be good to correlate with system events).

error compiling committee.c: too many arguments to function

reply via email to

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