[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: |
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?
Re: [Qemu-devel] Re: [PATCH 01/11] QMP: Introduce specification file, Anthony Liguori, 2009/06/23