From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MNvS7-0004YF-Ds for qemu-devel@nongnu.org; Mon, 06 Jul 2009 17:10:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MNvS2-0004My-O6 for qemu-devel@nongnu.org; Mon, 06 Jul 2009 17:10:19 -0400 Received: from [199.232.76.173] (port=41223 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNvS2-0004Ml-KB for qemu-devel@nongnu.org; Mon, 06 Jul 2009 17:10:14 -0400 Received: from moutng.kundenserver.de ([212.227.17.8]:62814) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MNvS2-0006rO-0S for qemu-devel@nongnu.org; Mon, 06 Jul 2009 17:10:14 -0400 Message-ID: <4A52682D.7000602@mail.berlios.de> Date: Mon, 06 Jul 2009 23:10:05 +0200 From: Stefan Weil MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] RFC: Add new block driver for the VDI format References: <4A4E5AFC.4020206@mail.berlios.de> <4A51FE07.2040307@codemonkey.ws> In-Reply-To: <4A51FE07.2040307@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , QEMU Developers Anthony Liguori schrieb: > Stefan Weil wrote: >> Hello, >> >> this mail will be followed by two patches which >> allow QEMU to create, read and write VDI images. >> VDI is the native image format of SUN's VirtualBox emulator. >> >> The code was written from scratch for QEMU, while earlier patches >> sent to Qemu-devel were wrappers for code from VirtualBox. See >> http://lists.gnu.org/archive/html/qemu-devel/2008-07/msg00366.html >> for those patches. >> >> Patch 1 adds uuid support to QEMU and can be used independent of >> the second patch (look for uuid in vl.c, for example). >> >> Patch 2 adds the VDI block driver. It only needs uuid support >> when a new image is created (without uuid, it will create an image >> with zeroed "uuid" values), so this second patch is semi-independent >> of the first. >> > > I'd really like to get rid of synchronous IO functions in the block > layer. One way to do this is to insist that all new block drivers > only implement the AIO functions. > > I think we should make this decree but I'd like to know if other > people think this is unreasonable first. One potential model of block > drivers would involve synchronous IO and threads. I'm not a big fan > of that model and I don't think it's an easy conversion from today's > synchronous IO drivers to that model because the locking and > re-entrance needs careful consideration. > > Since it looks like you're caching the full offset table in memory, > and it's a single level, making it asynchronous should be very easy to > do. > > Regards, > > Anthony Liguori > Yes, at least it should be straight forward to do. I planned to switch to AIO in a second stage. It would help if you could already commit the synchronous version as soon as the endianess issue (detected by Kevin Wolf, thanks) and an additional bug in the write code are fixed (code is ready, but still untested - a patch will follow this week). I don't plan to change the code's license from GPL to MIT. This is a matter of my personal taste. Is this a problem for new block driver code? Regards, Stefan Weil