From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3CfL-0001ME-OK for qemu-devel@nongnu.org; Thu, 01 Mar 2012 15:31:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3CfJ-0001rR-Dm for qemu-devel@nongnu.org; Thu, 01 Mar 2012 15:31:55 -0500 Received: from [199.101.231.129] (port=50631 helo=STC-EXCH.stc.local) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3CfJ-0001r5-6E for qemu-devel@nongnu.org; Thu, 01 Mar 2012 15:31:53 -0500 Message-ID: <4F4FDCB6.3060203@storagecraft.com> Date: Thu, 1 Mar 2012 13:31:50 -0700 From: Kai Meyer MIME-Version: 1.0 References: <4F4E9E31.50903@storagecraft.com> <4F4F8FCD.7010106@redhat.com> <4F4FD1C9.8050006@storagecraft.com> <4F4FD7C7.7030001@mail.berlios.de> <4F4FD9A6.9060308@mail.berlios.de> In-Reply-To: <4F4FD9A6.9060308@mail.berlios.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Add support for new image type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: Nate Bushman , qemu-devel@nongnu.org On 03/01/2012 01:18 PM, Stefan Weil wrote: > Am 01.03.2012 21:10, schrieb Stefan Weil: >> Am 01.03.2012 20:45, schrieb Kai Meyer: >>> On 03/01/2012 08:03 AM, Kevin Wolf wrote: >>>> Am 29.02.2012 22:52, schrieb Kai Meyer: >>>>> Is it possible to extend qemu to support a new image type? I have an >>>>> image type that is ready for consumption and I'm looking for the >>>>> integration point between qemu and the new image format. >>>> Which image format do you want to get integrated? >>>> >>>> Have a look at block/qcow2.c to get an idea of what a qemu block >>>> driver >>>> looks like. At the bottom of the file there is a struct that contains >>>> function pointers to all exported functions, so this is usually a good >>>> place to start exploring a driver. >>>> >>>> Kevin >>> >>> Great, this is exactly what we're after. I work for StorageCraft, >>> and we would like to figure out some way to allow qemu to directly >>> consume our image-based backups. It would provide us with user-space >>> mounting (via libguestfs) as well as booting VMs directly from >>> Backup images. We already have a proprietary image access library >>> that provides block-wise access to our image files. I have been able >>> to scratch together a proof of concept already, which I am really >>> pleased with. >>> >>> I see only two roadblocks for which I don't have immediate answers for. >>> >>> 1) Licensing >>> Is it possible to license our contributions in such a way that we do >>> not need to open the source code of our image access library? >> >> This is not possible if you want to link your image access library >> statically. >> >> QEMU uses GPL v2. You can use a patched QEMU internally, >> but as soon as you want to give it to customers (or get it integrated >> in the official source tree), you must publish all code which is needed >> under an open license. >> >> If your image access library is a shared library (linked at runtime), >> the situation is more difficult. The intention of the GPL is still >> that you have to publish your code (this is also what the FSF says), >> but there are different opinions for GPL v2. See >> http://en.wikipedia.org/wiki/GNU_General_Public_License for >> more information. >> >> I personally don't like the idea of QEMU supporting closed source >> shared libraries. >> >>> 2) External dependency on our image access library. >>> We do not want to force qemu to require our image access library to >>> be present to build. Would it be better to do a conditional build >>> (./configure --with-spf) or a run-time check for our image access >>> library? >> >> You'll need the conditional build for those people who don't want >> support >> for your image type. >> >> Regards, >> >> Stefan Weil > > > I forgot to mention a possible solution: instead of using your image > access library > (which is closed source), you could write new access code (maybe with > reduced > functionality) and publish that code under an open source license. > > QEMU uses this approach for some image types where we don't have the > original source code (for example block/vpc.c or block/vmdk.c). > > Regards, > Stefan Weil > I haven't planned on pitching that as a solution, but I will keep it in mind.