|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends |
Date: | Sun, 06 Dec 2009 20:19:37 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091203 Fedora/3.0-3.13.rc2.fc12 Thunderbird/3.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |