From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qk9Ud-00014R-Me for qemu-devel@nongnu.org; Fri, 22 Jul 2011 02:45:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qk9Uc-0005bi-Na for qemu-devel@nongnu.org; Fri, 22 Jul 2011 02:45:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qk9Uc-0005bX-DG for qemu-devel@nongnu.org; Fri, 22 Jul 2011 02:45:50 -0400 Message-ID: <4E291D4A.1090506@redhat.com> Date: Fri, 22 Jul 2011 08:48:42 +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> In-Reply-To: <20110721152354.GD3833@stefanha-thinkpad.localdomain> 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 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. 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