From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QkCTy-0005tG-Jx for qemu-devel@nongnu.org; Fri, 22 Jul 2011 05:57:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QkCTx-0006yN-EE for qemu-devel@nongnu.org; Fri, 22 Jul 2011 05:57:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62121) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QkCTx-0006yF-1T for qemu-devel@nongnu.org; Fri, 22 Jul 2011 05:57:21 -0400 Message-ID: <4E294A2D.4010101@redhat.com> Date: Fri, 22 Jul 2011 12:00:13 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1310748459-2119-1-git-send-email-kwolf@redhat.com> <1310748459-2119-10-git-send-email-kwolf@redhat.com> <20110721152354.GD3833@stefanha-thinkpad.localdomain> <4E291D4A.1090506@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH 9/9] block: Use bdrv_co_* instead of synchronous versions in coroutines List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org Am 22.07.2011 11:17, schrieb Stefan Hajnoczi: > On Fri, Jul 22, 2011 at 7:48 AM, Kevin Wolf wrote: >> 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 >>>> --- >>>> 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. > > Fair enough. I just want to make sure that we're working in the > direction of removing the synchronous stuff rather than propping it > up. Sure, I'm just trying to find an incremental approach to do it. >> 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. > > AIO interfaces should be kept because they do not have drawbacks like > synchronous interfaces. The AIO interfaces provide the most efficient > way of implementing raw. Sorry, my wording was ambiguous. I meant you could have argued before that synchronous bdrv_read/write calls in the device should be replaced by AIO ones. It's not something entirely new that only coroutines provide, they just provide it in a nicer way. Kevin