From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1McPzq-0005GI-Rx for qemu-devel@nongnu.org; Sat, 15 Aug 2009 16:37:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1McPzl-0005G5-9G for qemu-devel@nongnu.org; Sat, 15 Aug 2009 16:37:01 -0400 Received: from [199.232.76.173] (port=45571 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1McPzl-0005G2-4m for qemu-devel@nongnu.org; Sat, 15 Aug 2009 16:36:57 -0400 Received: from verein.lst.de ([213.95.11.210]:36852) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1McPzk-0003JH-Hr for qemu-devel@nongnu.org; Sat, 15 Aug 2009 16:36:56 -0400 Date: Sat, 15 Aug 2009 22:36:52 +0200 From: Christoph Hellwig Subject: Re: [Qemu-devel] [PATCH] Add tar container format Message-ID: <20090815203652.GA22040@lst.de> References: <1249486402-10824-1-git-send-email-agraf@suse.de> <4A849A40.3080205@codemonkey.ws> <1F7A05E1-0B0B-4C68-B07B-2F36B9BECF81@suse.de> <4A849E17.3030901@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A849E17.3030901@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Christoph Hellwig , Alexander Graf , qemu-devel@nongnu.org On Thu, Aug 13, 2009 at 06:13:27PM -0500, Anthony Liguori wrote: > What's attractive about doing plugins for the block layer is that we > have a relatively stable interface for block drivers. The current AIO > ops should be good for a very long time so API churn shouldn't be a > major issue. The code is all pretty well isolated today. > > As part of the longer term refactoring, I think it also makes sense to > split the block layer into a library that can be consumed independent of > QEMU. Obviously, folks want to make use of our block code who don't > care at all about QEMU. A lot of people use qemu-img for vmdk > manipulation, for instance. It also makes tools like qemu-iotest able > to consume the block layer in a saner way. > > If others agree, I think we should start going down this road. > block-tar/block-dictzip seem like obvious candidates for plugins. Splitting drivers from the core is a total desaster, you'll end up with the same crap as the X drivers vs core X server versioning mess. After a long stabilization period we might be able to split the block layer _including_ the drivers from qemu if we really want. Splitting the drivers into tiny subpackages would be plain stupid. As far as additional image formats are concerned I'm personally not a fan at all of any of that image format crap we have right now. Anything like qcow and friends or other formats that do complex metadata manipulation in userspace is a really bad idea for data integrity. Supporting simple containers with static metadata is absolutely fine, even more so it it's read-only like the tar container here. But one problem with tar is that there are many slightly or even totally different tar formats and extensions around. It's not nessecarily a format I would personally chose for a product. That's something the SuSE stuio people should think about, but nothing that should prevent us from including the format.