From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IzvXJ-0006yg-Ix for qemu-devel@nongnu.org; Wed, 05 Dec 2007 09:47:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IzvXH-0006wV-RD for qemu-devel@nongnu.org; Wed, 05 Dec 2007 09:47:40 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IzvXH-0006wK-HK for qemu-devel@nongnu.org; Wed, 05 Dec 2007 09:47:39 -0500 Received: from py-out-1112.google.com ([64.233.166.177]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IzvXH-0006jo-4M for qemu-devel@nongnu.org; Wed, 05 Dec 2007 09:47:39 -0500 Received: by py-out-1112.google.com with SMTP id j37so8876258pyc for ; Wed, 05 Dec 2007 06:47:38 -0800 (PST) Message-ID: <4756BA04.7060104@codemonkey.ws> Date: Wed, 05 Dec 2007 08:47:32 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O References: <11966765602186@bull.net> <4753D920.4060500@bellard.org> <1196677804.5275.5.camel@frecb07144> <475426C7.20503@codemonkey.ws> <20071203170800.GC3797@implementation> <47544588.10700@codemonkey.ws> <1196709044.5587.20.camel@frecb07144> <47547163.1020604@redhat.com> <47547753.2050101@codemonkey.ws> <4755545E.6090609@redhat.com> <47556C2F.1010304@codemonkey.ws> <47557DC8.7080206@redhat.com> In-Reply-To: <47557DC8.7080206@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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: qemu-devel@nongnu.org Gerd Hoffmann wrote: > Anthony Liguori wrote: > >> Gerd Hoffmann wrote: >> > Hi, > > >> I really want to use readv/writev though. With virtio, we get a >> scatter/gather list for each IO request. >> > > Yep, I've also missed pwritev (or whatever that syscall would be named). > > >> Once I post the virtio-blk driver, I'll follow up a little later with >> some refactoring of the block device layers. I think it can be made >> much simpler while still remaining asynchronous. >> >> >>> IMHO the only alternative to that scheme would be to turn the block >>> drivers in some kind of remapping drivers for the various file formats >>> which don't actually perform the I/O. Then you can handle the actual >>> I/O in a generic way using whatever API is available, be it posix-aio, >>> linux-aio or slow-sync-io. >>> >> That's part of my plan. >> > > Oh, cool. Can you also turn them into a sane shared library while being > at it? The current approach to compile it once for qemu and once for > qemu-img with -DQEMU_TOOL isn't that great. But if you factor out the > actual I/O the block-raw.c code should have no need to mess with qemu > internals any more and become much cleaner and simpler ... > Yeah, it is definitely something that should be turned into a shared library. I don't think I'll attempt that at first but I do agree it's the right direction to move toward. Regards, Anthony Liguori > cheers, > Gerd > > > > >