From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtiU6-0007gD-S3 for qemu-devel@nongnu.org; Fri, 02 Oct 2009 09:47:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtiU2-0007eA-Lf for qemu-devel@nongnu.org; Fri, 02 Oct 2009 09:47:46 -0400 Received: from [199.232.76.173] (port=37189 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtiU2-0007e2-FC for qemu-devel@nongnu.org; Fri, 02 Oct 2009 09:47:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62444) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MtiU1-0008BA-TH for qemu-devel@nongnu.org; Fri, 02 Oct 2009 09:47:42 -0400 Date: Fri, 2 Oct 2009 10:47:29 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH v1 00/14]: Initial QObject conversion Message-ID: <20091002104729.510d67de@doriath> In-Reply-To: <4AC5F646.9040800@redhat.com> References: <1254412245-10452-1-git-send-email-lcapitulino@redhat.com> <4AC5F646.9040800@redhat.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: Gerd Hoffmann Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, avi@redhat.com 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. One way to solve the problem could be to move the MonitorError pointer to the Monitor struct. 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.... Looks hard, doesn't it? The real problem behind all QMP work is that we're starting from a big amount of human-targeted functionality and trying to make it common so that it's useful for machines as well.