From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NAp3F-0006Ae-PO for qemu-devel@nongnu.org; Wed, 18 Nov 2009 13:14:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NAp3A-00067s-MA for qemu-devel@nongnu.org; Wed, 18 Nov 2009 13:14:45 -0500 Received: from [199.232.76.173] (port=55388 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NAp3A-00067b-Dw for qemu-devel@nongnu.org; Wed, 18 Nov 2009 13:14:40 -0500 Received: from lo.gmane.org ([80.91.229.12]:39071) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NAp39-0006BL-Oa for qemu-devel@nongnu.org; Wed, 18 Nov 2009 13:14:40 -0500 Received: from list by lo.gmane.org with local (Exim 4.50) id 1NAp2x-00049C-O9 for qemu-devel@nongnu.org; Wed, 18 Nov 2009 19:14:27 +0100 Received: from nat-pool-brq-t.redhat.com ([209.132.186.34]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Nov 2009 19:14:27 +0100 Received: from pbonzini by nat-pool-brq-t.redhat.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Nov 2009 19:14:27 +0100 From: Paolo Bonzini Date: Wed, 18 Nov 2009 19:13:38 +0100 Message-ID: References: <1258487037-24950-1-git-send-email-lcapitulino@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: Sender: news Subject: [Qemu-devel] Re: [PATCH 00/10]: QError v4 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > 2. It falls short of the requirement that clients can reasonably > classify errors they don't know. True. (Though adding a classification mechanism can be done later once we have an idea of what errors are there at all). > 3. It falls short of the requirement that clients can easily present a > human-readable error description to their human users, regardless of > whether they know the error or not. That's true. I would definitely have the interpolated desc field go on the wire too, as part of the JSON form of QError. > If I understand Dan correctly, machine-readable error code + > human-readable description is just fine, as long as the error code is > reasonably specific and the description is precise and complete. Have > we heard anything else from client developers? Then (except for the asynchronicity) the current qemu monitor protocol is also just fine, including the fact that we send migrate and get m\rmi\rmig\rmigr etc. back on the socket. "error while creating snapshot on '%s'" may be easy to parse, but looking at a dictionary field in { "filename" : "blah.img" } is easier, and at the same time solves issues with escaping weird characters in the file name. > * The crucial question for the client isn't "what exactly went wrong". > It is "how should I handle this error". Answering that question > should be easy (say, check the error code). Figuring out what went > wrong should still be possible for a human operator of the client. The same error can be handled in a different way depending on the situation. A missing image is in general a fatal error, but maybe another client could create images on the fly. > Based on what I've learned about client requirements so far, I figure > that solution is "easily classified error code + human-readable > description". How would you classify the error code? By subsystem or by (for example) severity or anything else? Does QEMU have subsystems that are well-identified enough to be carved in stone in QError? (All genuine questions. I have no idea). Paolo