From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbjUF-0007Jc-R6 for qemu-devel@nongnu.org; Thu, 13 Aug 2009 19:13:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbjUA-0007H2-Qy for qemu-devel@nongnu.org; Thu, 13 Aug 2009 19:13:35 -0400 Received: from [199.232.76.173] (port=49671 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbjUA-0007Gy-Mn for qemu-devel@nongnu.org; Thu, 13 Aug 2009 19:13:30 -0400 Received: from qw-out-1920.google.com ([74.125.92.150]:63510) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MbjUA-0001tt-BR for qemu-devel@nongnu.org; Thu, 13 Aug 2009 19:13:30 -0400 Received: by qw-out-1920.google.com with SMTP id 5so369105qwc.4 for ; Thu, 13 Aug 2009 16:13:29 -0700 (PDT) Message-ID: <4A849E17.3030901@codemonkey.ws> Date: Thu, 13 Aug 2009 18:13:27 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add tar container format References: <1249486402-10824-1-git-send-email-agraf@suse.de> <4A849A40.3080205@codemonkey.ws> <1F7A05E1-0B0B-4C68-B07B-2F36B9BECF81@suse.de> In-Reply-To: <1F7A05E1-0B0B-4C68-B07B-2F36B9BECF81@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Kevin Wolf , qemu-devel@nongnu.org, Christoph Hellwig Alexander Graf wrote: > >> I'd almost rather see something like gio integration so that this >> sort of generic filesystem stuff could live somewhere else. I'm >> curious what others think though. Does it seem reasonable to include >> this type of functionality? > > > A plugin infrastructure sounds nice at first, but doesn't do all the > fedoras and ubuntus out there too much good ;-). If we did plugins, it would not be a GPL-safe boundary so all plugins would be forced to be GPL. 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. Regards, Anthony Liguori > Alex