From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nfcfz-00041t-6Z for qemu-devel@nongnu.org; Thu, 11 Feb 2010 12:18:03 -0500 Received: from [199.232.76.173] (port=41169 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nfcfy-00041f-QH for qemu-devel@nongnu.org; Thu, 11 Feb 2010 12:18:02 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nfcfx-0007E6-4M for qemu-devel@nongnu.org; Thu, 11 Feb 2010 12:18:02 -0500 Received: from mail-iw0-f194.google.com ([209.85.223.194]:60614) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nfcfw-0007Dw-Ku for qemu-devel@nongnu.org; Thu, 11 Feb 2010 12:18:00 -0500 Received: by iwn32 with SMTP id 32so2464772iwn.14 for ; Thu, 11 Feb 2010 09:17:59 -0800 (PST) Message-ID: <4B743BB6.2060504@codemonkey.ws> Date: Thu, 11 Feb 2010 11:17:42 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v0 00/21]: Monitor: improve handlers error handling References: <1265853007-27300-1-git-send-email-lcapitulino@redhat.com> <4B740E7A.9060105@codemonkey.ws> <4B742C6D.40006@codemonkey.ws> In-Reply-To: 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: Markus Armbruster Cc: qemu-devel@nongnu.org, Luiz Capitulino On 02/11/2010 10:57 AM, Markus Armbruster wrote: > Yes, that's a sensible argument. It's also quite impractical at this > time. In fact, I had the same idea, and dropped it like a hot potato > when I realized how much code we'd have to touch for it. > Can you give me an example of where it gets particularly ugly? It doesn't look so bad to me. > Because besides the single call chain func3(), func2(), func1(), there > are many more, and large parts of them never heard of the monitor or > qerror/qobject. There are places that happily ignore errors (and > nevertheless work tolerably well), and they all become memory leaks if > we change the error value from int to qobject. > > Look, we're sitting in a nice hole with QMP right now. We set ambitious > goals, we've been working on it for months, and we got quite some code, > but the result is still not useful. It really needs to become useful as > soon as possible. > > Once we made it out of this hole, I'll be game for refactoring stuff to > make it more flexible and less ugly. But as long as I'm sitting in this > hole, I'd prefer not to dig deeper. > Yeah, I can accept this argument provided that we're all in agreement for where we're going long term. I'd still like to understand the pragmatic issue that we're facing right now though. Regards, Anthony Liguori >> The current qerror stuff is really only useful within a single >> function. Once you start building infrastructure around qerror, it >> becomes very difficult to deal with. >> > [...] >