qemu-devel
[Top][All Lists]
Advanced

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

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


From: Luiz Capitulino
Subject: [Qemu-devel] Re: [PATCH 01/11] QMP: Introduce specification file
Date: Tue, 23 Jun 2009 10:22:30 -0300

On Tue, 23 Jun 2009 10:57:54 +0100
"Daniel P. Berrange" <address@hidden> wrote:

> > >+ o Command completion failed
> > >+
> > >+    Format: - ERR<reason>
> > >+    Example: - ERR could not find network device 'foo'
> > >+
> > >   
> > 
> > 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. 

 I have followed IMAP's design on this, which specifies that commands
execution errors are "- ERR" and protocol errors are "- BAD".

 So, commands that don't exist are protocol errors and applications
can distinguish them.

> > >+4.3 Events
> > >+----------
> > >+
> > >+Client queries the Server about memory, but QEMU reboots.
> > >+
> > >+S: + OK QEMU 0.10.50 QMP 0.1
> > >+C: info balloon
> > >+S: * EVENT reboot
> > >   
> > 
> > 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. 

 They will be ordered, but I liked the timestamp idea. Do you think it's
going to useful only for events, as suggested by Avi?





reply via email to

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