From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MsM6R-0001wH-1F
	for qemu-devel@nongnu.org; Mon, 28 Sep 2009 15:41:43 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MsM6M-0001qd-4L
	for qemu-devel@nongnu.org; Mon, 28 Sep 2009 15:41:42 -0400
Received: from [199.232.76.173] (port=33971 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MsM6M-0001qV-0q
	for qemu-devel@nongnu.org; Mon, 28 Sep 2009 15:41:38 -0400
Received: from mx1.redhat.com ([209.132.183.28]:19664)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <lcapitulino@redhat.com>) id 1MsM6L-0001xr-HK
	for qemu-devel@nongnu.org; Mon, 28 Sep 2009 15:41:37 -0400
Received: from int-mx05.intmail.prod.int.phx2.redhat.com
	(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8SJfZj7023858
	for <qemu-devel@nongnu.org>; Mon, 28 Sep 2009 15:41:35 -0400
Date: Mon, 28 Sep 2009 16:41:27 -0300
From: Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/3] Clean up error handling in net.c
Message-ID: <20090928164127.4f3c6641@doriath>
In-Reply-To: <cover.1254164473.git.armbru@redhat.com>
References: <cover.1254164473.git.armbru@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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org

On Mon, 28 Sep 2009 21:11:32 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> Caveat: I'm not familiar with slirp, and I'm not sure 1/3 is the right
> thing to do.

 FWIW, I'm working on a infrastructure for error handling in the Monitor.

 The goal is not only to fix abort/don't abort cases, but also to pass
error information up in the call stack, so that the protocol can emit it.

 So, in case you are planning to fix more of those abort cases, I would
really appreciate if you do this as part of a QObject conversion,
otherwise I would have to re-visit the handler to do the conversion
myself.

 I should post patches this week, although I'm not sure if I've picked
up the best API design for this...