From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ2uH-0001lo-Nv for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:07:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ2uD-0001kM-PH for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:07:13 -0400 Received: from [199.232.76.173] (port=51656 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ2uD-0001kD-HS for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:07:09 -0400 Received: from mx20.gnu.org ([199.232.41.8]:61445) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJ2uC-0001zl-Uh for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:07:09 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ2uC-0002Jg-0K for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:07:08 -0400 Message-ID: <4A40A980.1060602@redhat.com> Date: Tue, 23 Jun 2009 13:08:00 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20090623012811.53a62493@doriath> <4A40989C.1050805@redhat.com> <20090623095754.GC6881@redhat.com> In-Reply-To: <20090623095754.GC6881@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, Luiz Capitulino 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