From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTzCV-0008Gg-Na for qemu-devel@nongnu.org; Tue, 07 Jun 2011 12:32:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTzCT-0000yz-EU for qemu-devel@nongnu.org; Tue, 07 Jun 2011 12:32:19 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:58501) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTzCT-0000yn-4R for qemu-devel@nongnu.org; Tue, 07 Jun 2011 12:32:17 -0400 Received: by gyg4 with SMTP id 4so2519510gyg.4 for ; Tue, 07 Jun 2011 09:32:16 -0700 (PDT) Message-ID: <4DEE528E.2020002@codemonkey.ws> Date: Tue, 07 Jun 2011 11:32:14 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20110601181255.077fb5fd@doriath> <4DE6B087.6010708@codemonkey.ws> <20110602145730.4c80d668@doriath> <4DE7CFA4.9040300@codemonkey.ws> <20110602150900.7d2657fb@doriath> <4DEC9D07.5080409@redhat.com> <4DECD163.9030704@codemonkey.ws> <20110607114609.1938a2c3@doriath> <4DEE4641.9000807@codemonkey.ws> <20110607125428.4549540a@doriath> In-Reply-To: <20110607125428.4549540a@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QMP: RFC: I/O error info & query-stop-reason List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Kevin Wolf , Stefan Hajnoczi , jdenemar@redhat.com, qemu-devel@nongnu.org, Markus Armbruster On 06/07/2011 10:54 AM, Luiz Capitulino wrote: > On Tue, 07 Jun 2011 10:39:45 -0500 > Anthony Liguori wrote: > >> On 06/07/2011 09:46 AM, Luiz Capitulino wrote: >>> On Mon, 06 Jun 2011 08:08:51 -0500 >>> Anthony Liguori wrote: >>> >>>> On 06/06/2011 04:25 AM, Kevin Wolf wrote: >>>>> Am 02.06.2011 20:09, schrieb Luiz Capitulino: >>>>>>>> I'm ok with either way. But in case you meant the second one, I guess >>>>>>>> we should make "reason" a dictionary so that we can group related >>>>>>>> information when we extend the field, for example: >>>>>>>> >>>>>>>> "reason": { "no space": false, "no permission": true } >>>>> >>>>> Splitting up enums into a number of booleans looks like a bad idea to >>>>> me. It makes things more verbose than they should be, and even worse, it >>>>> implies that more than one field could be true. >>>> >>>> I agree. What I had suggested was to not have a reason at all. >>> >>> Is it better if we add a new enum to query-block? Like the "io-error" key we >>> have talked about earlier? Like: >>> >>> "io-error": "no space" >> >> 1) enums have to follow some rules. One obvious rule would be there >> can't be spaces in the enum value. >> >> 2) Do we have an defined enum values besides no-space? If not, let's >> not artificially add an enum. >> >>> >>> We could have "no space", "low level" (that's how the man page defines EIO) and >>> "unknown". >> >> 3) what's the difference between "no space" and "low level"? > > The latter means the device doesn't have enough space to write more data, > the former is I/O I guess it's more device specific. Sorry, I meant to ask, what's the difference between "low level" and "unknown". Regards, Anthony Liguori > > What's your suggestion? >