From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O9jtL-0007mp-62 for qemu-devel@nongnu.org; Wed, 05 May 2010 15:04:19 -0400 Received: from [140.186.70.92] (port=33818 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9jTb-00047w-Qf for qemu-devel@nongnu.org; Wed, 05 May 2010 14:37:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O9jKe-0003If-CQ for qemu-devel@nongnu.org; Wed, 05 May 2010 14:28:29 -0400 Received: from verein.lst.de ([213.95.11.210]:55506) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O9jKe-00039Y-1l for qemu-devel@nongnu.org; Wed, 05 May 2010 14:28:28 -0400 Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id o45IRKWY008519 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 5 May 2010 20:27:20 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-7.2) id o45IRKrO008518 for qemu-devel@nongnu.org; Wed, 5 May 2010 20:27:20 +0200 Date: Wed, 5 May 2010 20:27:20 +0200 From: Christoph Hellwig Message-ID: <20100505182719.GA8067@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] Fate of the read-only block drivers? List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Currently we have four very simple, read-only block drivers in the tree: - cloop: This one is known buggy for non-trivial use and didn't get any chance but the usual API changes and cleanup sweeps since it was commited in 2004. - dmg: This one is really grotty and by auditing the code and comparing it to dmg2img completely buggy for non-compressed chunks. It's also missing lots of the features in modern dmg image. Also there's no creation tool for Linux. No non-trivial commits since the initial import in 2004. - bochs: There is an bximage tools to actually create images for it, but not to actually add any content to them. It had one non-trivial commit in 2007 to add support for growable formats since it's initial commit in 2004. - parallels: I can't find any way to actually create the image except with the parallels image tool which seems to require a commercial parallels license. No non-trivial commits since the initial import in 2007. At this point I'm not sure if it's worth bothering to fix these up, as they're bitrotted and except for cloop there's no reasy way to actually create test images for them. Any good reason to keep them, and if yes any good idea for a test plan to keep them working?