From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QU0JH-0001hp-A8 for qemu-devel@nongnu.org; Tue, 07 Jun 2011 13:43:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QU0JF-0005QE-6X for qemu-devel@nongnu.org; Tue, 07 Jun 2011 13:43:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QU0JE-0005Q6-LI for qemu-devel@nongnu.org; Tue, 07 Jun 2011 13:43:21 -0400 Date: Tue, 7 Jun 2011 14:43:14 -0300 From: Luiz Capitulino Message-ID: <20110607144314.4368c08b@doriath> In-Reply-To: <4DEE528E.2020002@codemonkey.ws> 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> <4DEE528E.2020002@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Anthony Liguori Cc: Kevin Wolf , Stefan Hajnoczi , jdenemar@redhat.com, qemu-devel@nongnu.org, Markus Armbruster On Tue, 07 Jun 2011 11:32:14 -0500 Anthony Liguori wrote: > 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". "low level" is EIO, "unknown" is everything else (EINVAL, EPIPE, ...). > > Regards, > > Anthony Liguori > > > > > What's your suggestion? > > >