qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Add support for new image type


From: Stefan Weil
Subject: Re: [Qemu-devel] Add support for new image type
Date: Thu, 01 Mar 2012 21:53:25 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120207 Iceowl/1.0b1 Icedove/3.0.11

Am 01.03.2012 21:26, schrieb Kai Meyer:
On 03/01/2012 01:10 PM, Stefan Weil wrote:
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.
It is a shared library.

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.
My primary concern right now is if it is a reasonable course of action. I will eventually rely on our internal processes to determine how to remain in compliance with exiting licenses.
http://wiki.qemu.org/License
Portions of qemu (ie the qed block driver) are licensed under the LGPL. Can you help me understand the impact of licensing our contributions under the LGPL instead of GPL?

If you use the LGPL for your contributions, you grant other people more rights
than they would have with the GPL (which I think is not what you want).

Using GPL for your image access library does _not_ imply that you cannot use it
in other closed source projects! You are the copyright owner, so you may do
anything you want with your library, even when you grant others the right to
use it under GPL.

Regards,
Stefan Weil




reply via email to

[Prev in Thread] Current Thread [Next in Thread]