qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH 9/9] block: Use bdrv_co_* instead of synchr


From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC][PATCH 9/9] block: Use bdrv_co_* instead of synchronous versions in coroutines
Date: Fri, 22 Jul 2011 08:48:42 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc15 Thunderbird/3.1.11

Am 21.07.2011 17:23, schrieb Stefan Hajnoczi:
> On Fri, Jul 15, 2011 at 06:47:39PM +0200, Kevin Wolf wrote:
>> If we're already in a coroutine, there is no reason to use the synchronous
>> version of block layer functions when a coroutine one exists. This makes
>> bdrv_read/write/flush use bdrv_co_* when used inside a coroutine.
>>
>> Signed-off-by: Kevin Wolf <address@hidden>
>> ---
>>  block.c |   43 +++++++++++++++++++++++++++++++++++++++++++
>>  1 files changed, 43 insertions(+), 0 deletions(-)
> 
> I made similar changes to prototype qcow2 coroutines.  They allowed
> synchronous code to run unmodified inside a coroutine.
> 
> But do we want to keep the synchronous APIs?  They tend to be misused
> because they allow synchronous implementation of devices (extboot,
> onenand, and others).
> 
> The only reason to keep these around is for qemu-img and perhaps some
> startup code before the VM is running.  But I think we could tackle
> those cases too simply by running in a coroutine and using a common
> event loop (which makes timers and bottom halves work too).

One change at a time. :-)

This series is manageable, can be reviewed in finite time and gives us
the immediate benefit of not blocking the VCPU any more. I know that
some tend to rewrite half of qemu for every idea they have, but I'd
prefer a more incremental approach.

Removing all synchronous bdrv_read/write calls from the devices is a
task that I wouldn't underestimate, and at the same time a completely
unrelated task (you could have suggested the same with AIO callbacks). I
agree that we should do this change some time, but for now devices get
exactly what they got before.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]