From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KiCFu-0004BN-LJ for qemu-devel@nongnu.org; Tue, 23 Sep 2008 14:04:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KiCFt-0004AW-29 for qemu-devel@nongnu.org; Tue, 23 Sep 2008 14:04:58 -0400 Received: from [199.232.76.173] (port=39874 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KiCFs-0004AT-Pq for qemu-devel@nongnu.org; Tue, 23 Sep 2008 14:04:56 -0400 Received: from mx2.redhat.com ([66.187.237.31]:43692) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KiCFs-0005QM-7y for qemu-devel@nongnu.org; Tue, 23 Sep 2008 14:04:56 -0400 Message-ID: <48D92FC2.2000203@redhat.com> Date: Tue, 23 Sep 2008 20:04:50 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2/3] Move aio implementation out of raw block driver References: <1222125454-21744-1-git-send-email-ryanh@us.ibm.com> <1222125454-21744-3-git-send-email-ryanh@us.ibm.com> <48D85849.2080302@us.ibm.com> <20080923143909.GK31395@us.ibm.com> <48D902EB.8070701@redhat.com> <48D91403.8090007@us.ibm.com> In-Reply-To: <48D91403.8090007@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Ryan Harper , qemu-devel@nongnu.org, kvm@vger.kernel.org, Marcelo Tosatti Anthony Liguori wrote: > Gerd Hoffmann wrote: >> How about providing a aio interface implementation which simply uses >> read/write syscalls (thereby not being really async obviously)? Then >> use that as fallback instead of aio emulation? And also drop CONFIG_AIO >> then? > > Yeah, this is basically what block-raw-posix does today. I was thinking > the same thing. I was also thinking that you could do an aio > implementation for win32 and possibly reunify block-raw-posix and > block-raw-linux. Sure, that the next logical steps. Later we can also convert all block-* drivers to the new aio interface and subsequently drop alot of dead block layer code. > But before going down this route, I want to see if linux-aio is really > the right tool for the job. IMHO this all makes sense even in case linux-aio turns out to not be worth it. cheers, Gerd