From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NHLiF-0007p0-R8
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 13:20:03 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NHLiB-0007km-26
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 13:20:03 -0500
Received: from [199.232.76.173] (port=35107 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NHLiA-0007kj-Ud
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 13:19:58 -0500
Received: from mx1.redhat.com ([209.132.183.28]:6778)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1NHLiA-0004XV-I9
	for qemu-devel@nongnu.org; Sun, 06 Dec 2009 13:19:58 -0500
Message-ID: <4B1BF5B9.50608@redhat.com>
Date: Sun, 06 Dec 2009 20:19:37 +0200
From: Avi Kivity <avi@redhat.com>
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>
	<Pine.LNX.4.64.0912062109330.4378@linmac.oyster.ru>
In-Reply-To: <Pine.LNX.4.64.0912062109330.4378@linmac.oyster.ru>
Content-Type: text/plain; charset=UTF-8; format=flowed
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: malc <av1474@comtv.ru>
Cc: Paul Brook <paul@codesourcery.com>, Ian Molton <ian.molton@collabora.co.uk>, qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>

On 12/06/2009 08:12 PM, malc 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.
>>      
> Here, i do agree, but mostly because most of the users of allocation
> functions just themselves returned NULL or -1 or whatever and never
> really bothered to report anything, so the addition of OOM check that
> you've added made the code less cluttered.
>    

My point is that it would take a major rework, and would probably 
involve removing the allocations instead of handling any errors.  For 
example, a scsi device would tell the block device the upper bound of 
aiocbs it could possibly issue, and the maximum number of sg elements in 
a request, and qcow2 (or any other backing format driver) would 
preallocate enough resources to satisfy the worst case.  And we still 
can't handle a syscall returning ENOMEM.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.