From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mtix7-0001hj-2N for qemu-devel@nongnu.org; Fri, 02 Oct 2009 10:17:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mtix2-0001hX-Dq for qemu-devel@nongnu.org; Fri, 02 Oct 2009 10:17:44 -0400 Received: from [199.232.76.173] (port=60615 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mtix2-0001hU-87 for qemu-devel@nongnu.org; Fri, 02 Oct 2009 10:17:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62253) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mtix1-0004vj-RZ for qemu-devel@nongnu.org; Fri, 02 Oct 2009 10:17:40 -0400 Message-ID: <4AC60B7F.5040809@redhat.com> Date: Fri, 02 Oct 2009 16:17:35 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v1 00/14]: Initial QObject conversion References: <1254412245-10452-1-git-send-email-lcapitulino@redhat.com> <4AC5F646.9040800@redhat.com> <20091002104729.510d67de@doriath> In-Reply-To: <20091002104729.510d67de@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, avi@redhat.com On 10/02/09 15:47, Luiz Capitulino wrote: > On Fri, 02 Oct 2009 14:47:02 +0200 > Gerd Hoffmann wrote: > >> Hi, >> >>> Some people have suggested that we should have a better error handling >>> in the Monitor, in the meaning that error information should be correctly >>> propagated and handled in order to be used by the Monitor Protocol and >>> the existing user protocol. >> >> A bunch of code paths can be called from both monitor and non-monitor >> contexts (network configuration, device hotplug). Right now there are >> the qemu_error*() functions to make sure the error messages appear on >> the correct place (monitor or stderr) without having to pass through a >> Monitor pointer all the way down. >> >> How do you plan to handle this in the new world of monitor error reporting? > > Good question. > > The first thing to bear in mind is that MonitorError is not just about > error reporting, but more importantly, it makes errors have a common > structure so that they can be emitted by the Monitor Protocol. So maybe they shouldn't be named MonitorError in the first place? And make sure the design works for non-monitor contexts too? Having the user_error callback in struct mon_cmd_t doesn't make sense from that point of view for example. Why user_error is needed in the first place btw? To maintain backward-compatible error message formating? > One way to solve the problem could be to move the MonitorError pointer > to the Monitor struct. I think that is a good idea nevertheless. > This way, when there's a ERR_SINK_MONITOR > qemu_error() would fill MonitorError instead of calling monitor_vprintf(). > > The bad news though, is that we would have to change all qemu_error() > calls to have "structured" errors instead of pretty printing, that is, > create macros, define its errors data and write functions to do > pretty printing.... Or add a qemu_error_structed() variant for smooth switchover and have qemu_error() use a generic error code, so you don't have to switch over all at once. There are not *that* many qemu_error users though, so just converting them all in one go might not be too hard. cheers, Gerd