From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NAquI-0003aX-U7 for qemu-devel@nongnu.org; Wed, 18 Nov 2009 15:13:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NAquD-0003Yq-Ha for qemu-devel@nongnu.org; Wed, 18 Nov 2009 15:13:38 -0500 Received: from [199.232.76.173] (port=36976 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NAquD-0003Yn-7e for qemu-devel@nongnu.org; Wed, 18 Nov 2009 15:13:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55551) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NAquC-0002ET-NZ for qemu-devel@nongnu.org; Wed, 18 Nov 2009 15:13:33 -0500 Date: Wed, 18 Nov 2009 18:13:21 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH 07/10] Introduce QError Message-ID: <20091118181321.5f9e668f@doriath> In-Reply-To: <4B0451D9.9080505@linux.vnet.ibm.com> References: <1258487037-24950-1-git-send-email-lcapitulino@redhat.com> <1258487037-24950-8-git-send-email-lcapitulino@redhat.com> <20091118181456.GA29178@redhat.com> <4B0451D9.9080505@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kraxel@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com On Wed, 18 Nov 2009 13:58:17 -0600 Anthony Liguori wrote: > Daniel P. Berrange wrote: > > On Tue, Nov 17, 2009 at 05:43:54PM -0200, Luiz Capitulino wrote: > > > >> QError is a high-level data type which represents an exception > >> in QEMU, it stores the following error information: > >> > >> - class Error class name (eg. "ServiceUnavailable") > >> - description A detailed error description, which can contain > >> references to run-time error data > >> - filename The file name of where the error occurred > >> - line number The exact line number of the error > >> > > > > If we're going to collect these two, then also add in the function > > name, since that's typically more useful than filename/line number > > alone. > > > > I'm not convinced it's a good idea to put that info on the wire. It's > unstable across any build of qemu. However, since it's extra info, it > doesn't bother me that much if people think it's useful for debugging > purposes. It's really for debugging, so that we can have a detailed error description when the error macro has a wrong syntax. That said, we could have a compile time switch to activate extra debugging information on the wire. But that's a brainstorm.