From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRKmD-00012L-Na for qemu-devel@nongnu.org; Tue, 09 Sep 2014 08:44:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XRKm7-0007y6-CA for qemu-devel@nongnu.org; Tue, 09 Sep 2014 08:44:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRKm7-0007xD-4X for qemu-devel@nongnu.org; Tue, 09 Sep 2014 08:43:59 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s89ChvuI002119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 9 Sep 2014 08:43:58 -0400 Date: Tue, 9 Sep 2014 08:43:53 -0400 From: Luiz Capitulino Message-ID: <20140909084353.454cc889@redhat.com> In-Reply-To: <540EF48B.5090705@redhat.com> References: <20140829160727.69f66ecd@redhat.com> <20140908104217.48f2354a@redhat.com> <20140908153318.GH4297@noname.redhat.com> <20140908125701.3be785e9@redhat.com> <20140909082733.GD4847@noname.str.redhat.com> <540EF48B.5090705@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] block: extend BLOCK_IO_ERROR event with nospace indicator List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , fromani@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com On Tue, 09 Sep 2014 06:37:31 -0600 Eric Blake wrote: > On 09/09/2014 02:27 AM, Kevin Wolf wrote: > > >>> > >>> What was our conclusion wrt the human-readable strerror() string for > >>> debugging? Didn't we want to add that as well? > >> > >> I can do it on top of this patch. So, just adding a new field for this > >> is fine? > > > > I think so. Perhaps we should give it an 'x-' name to make clear that > > it's a debugging help and not supposed to be parsed by management tools. > > Or would that be abuse of that namespace? > > I think using x- would be okay for the namespace, but am not sure we > need to go that far. We already have other fields without x- that are > documented as human-readable only; for example, CommandLineParameterInfo > has: > > # @help: #optional human readable text string, not suitable for parsing. > > or in our events, QUORUM_REPORT_BAD has: > > # @error: #optional, error message. Only present on failure. This field > # contains a human-readable error message. There are no > semantics other > # than that the block layer reported an error and clients should not > # try to interpret the error string. > > So I'd be fine with something as simple as 'message' or 'error'. > > > > > The alternative solution (or actually we could do both) would be to > > store it somewhere in bs and put it into query-block. > > Enhancing query-block in addition to the event makes sense, if it is > easy enough to do. At this point, we are talking about debugging aids, > so as long as they are documented appropriately, I won't be too fussy. OK, but I'm wondering if we need to add the string field to both, BLOCK_IO_ERROR and query-block, or only to one to the other. In my opinion, we should only add it to BLOCK_IO_ERROR if libvirt is going to consume. Otherwise, it makes more sense to add it to query-block because that's where we'll meet the user. Btw, by "consume" I mean read it and make it available to libvirt clients so that they can print it to their users. If we don't want libvirt to consume that field then I think we should only add it to query-block and info block.