From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SulVK-0004oN-Oj for qemu-devel@nongnu.org; Fri, 27 Jul 2012 10:27:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SulVE-0001Nt-Ql for qemu-devel@nongnu.org; Fri, 27 Jul 2012 10:26:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23307) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SulVE-0001NW-IJ for qemu-devel@nongnu.org; Fri, 27 Jul 2012 10:26:52 -0400 Date: Fri, 27 Jul 2012 11:27:29 -0300 From: Luiz Capitulino Message-ID: <20120727112729.60f009c3@doriath.home> In-Reply-To: <501294DB.1050304@suse.de> References: <1343249431-9245-1-git-send-email-lcapitulino@redhat.com> <87ehnyv7p8.fsf@blackfin.pond.sub.org> <50116A48.1050307@redhat.com> <20120726133724.293bf8b1@doriath.home> <501294DB.1050304@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC 00/14]: add printf-like human msg to error_set() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?ISO-8859-1?B?RuRyYmVy?= Cc: peter.maydell@linaro.org, Paolo Bonzini , aliguori@us.ibm.com, Markus Armbruster , qemu-devel@nongnu.org On Fri, 27 Jul 2012 15:17:15 +0200 Andreas F=E4rber wrote: > Am 26.07.2012 18:37, schrieb Luiz Capitulino: > > On Thu, 26 Jul 2012 18:03:20 +0200 > > Paolo Bonzini wrote: > >=20 > >> Il 26/07/2012 17:54, Markus Armbruster ha scritto: > >>> Unlike Anthony, I think this is a move in the right direction. > >> > >> Me too, but I would like to understand how it fits with the > >> qapi-schema-errors.json. Do we actually need a schema if the messages > >> are flat? > >=20 > > Yes, we need it because we still an error object to obey (ie. the data = member). > >=20 > > But we're talking about dropping that, so it might be possible to kill > > the schema. >=20 > I'm not so familiar with how all this error infrastructure is plugged > together... >=20 > In a different thread that I mentioned recently (and still haven't found > in my inbox), we were talking about changing the JSON encoding of errors > where unused by libvirt. Specifically we were talking about having a > field for the canonical QOM path of the affected object in place of the > often-empty device ID. We don't send empty device IDs afaik, but that problem will have to be discussed again... Why does libvirt need the QOM path from the error message? Can't it be queried some other way?