From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NHPlY-0002hK-RB
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 17:39:44 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NHPlX-0002gJ-DJ
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 17:39:44 -0500
Received: from [199.232.76.173] (port=39450 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NHPlW-0002g2-Vi
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 17:39:43 -0500
Received: from bhuna.collabora.co.uk ([93.93.128.226]:41157)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <ian.molton@collabora.co.uk>) id 1NHPlW-0000R2-IO
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 17:39:43 -0500
Message-ID: <4B1C3282.70009@collabora.co.uk>
Date: Sun, 06 Dec 2009 22:38:58 +0000
From: Ian Molton <ian.molton@collabora.co.uk>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends
References: <m3skbwxgkp.fsf@crossbow.pond.sub.org>	<4B193DA5.6040507@codemonkey.ws>
	<4B1A9359.8080305@redhat.com>	<4B1A9811.8020108@codemonkey.ws>	<m3vdgky0za.fsf@crossbow.pond.sub.org>	<4B1BE153.6070509@collabora.co.uk>
	<4B1BE691.1010401@redhat.com>	<Pine.LNX.4.64.0912062039420.4300@linmac.oyster.ru>
	<4B1BF1A0.4030002@redhat.com>
In-Reply-To: <4B1BF1A0.4030002@redhat.com>
Content-Type: text/plain; charset=UTF-8
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: Avi Kivity <avi@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>, Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org

Avi Kivity wrote:

> Init is pretty easy to handle.  I'm worried about runtime where you
> can't report an error to the guest.  Real hardware doesn't oom.

In the case of the socket reconnect code I posted recently, if the
allocation failed, it would give up trying to reconnect and inform the
user of that chardev that it had closed. Ok, this doesnt help the guest,
but it allows other code to clean up nicely, and we can report the
failure to the host. IMHO thats better than leaving a sysadmin
scratching their head wondering why it suddenly just stopped feeding the
guest entropy and isnt trying to reconnect anymore...

(IMO)

-Ian