From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ5xU-0001oG-LW for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:22:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ5xP-0001ez-Tp for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:22:44 -0400 Received: from [199.232.76.173] (port=39631 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ5xP-0001eZ-F3 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:22:39 -0400 Received: from mx2.redhat.com ([66.187.237.31]:43280) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ5xO-0007Nv-TJ for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:22:39 -0400 Date: Tue, 23 Jun 2009 10:22:30 -0300 From: Luiz Capitulino Message-ID: <20090623102230.4be446d2@doriath> In-Reply-To: <20090623095754.GC6881@redhat.com> References: <20090623012811.53a62493@doriath> <4A40989C.1050805@redhat.com> <20090623095754.GC6881@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 01/11] QMP: Introduce specification file List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: aliguori@us.ibm.com, ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Avi Kivity On Tue, 23 Jun 2009 10:57:54 +0100 "Daniel P. Berrange" wrote: > > >+ o Command completion failed > > >+ > > >+ Format: - ERR > > >+ 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?