From: Saggi Mizrahi <smizrahi@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/2] Added target to build libvdisk
Date: Wed, 24 Aug 2011 14:32:16 +0300 [thread overview]
Message-ID: <4E54E140.1060809@redhat.com> (raw)
In-Reply-To: <4E53D3A4.3070306@codemonkey.ws>
On Tue 23 Aug 2011 07:21:56 PM IDT, Anthony Liguori wrote:
> On 08/23/2011 11:18 AM, Daniel P. Berrange wrote:
>> On Tue, Aug 23, 2011 at 11:14:20AM -0500, Anthony Liguori wrote:
>>> On 08/23/2011 11:12 AM, Daniel P. Berrange wrote:
>>>> $(block-obj-y) pulls in 'aio.o' which is built from aio.c which
>>>> is licensed "GPLv2 only". So even those many files are BSD
>>>> licenses, the combined work will be GPLv2-only. Unfortunately ending
>>>> up with a libqemublock.so which is GPLv2-only is as good as useless
>>>> for libs/apps since it is incompatible with both LGPLv2(+) and GPLv3.
>>>>
>>>> Now in this case aio.c is labelled as Copyright IBM / Anthony,
>>>> so IBM could likely resolve this licensing to be more widely
>>>> compatible. This could^H^Hwould become a non-trivial task if we
>>>> need to look at many files& then also any patches accepted to
>>>> those files from 3rd parties over the years :-(
>>>
>>> If there was a block driver library, I would expect it to be GPL, not
>>> LGPL.
>>
>> This would prevent us from using it in libvirt, unless we wrote a
>> helper program which we spawned anytime we wanted to use some
>> functionality library :-(
>
> libvirtd is GPL, no?
>
> But QEMU is GPL. Libraries derived from QEMU will also be GPL.
>
> Regards,
>
> Anthony Liguori
>
>>
>> Regards,
>> Daniel
OK, I admit it was a pretty naive solution. But I always try to do the
simplest solution first.
The license issues can be solved later. (Having it as GPL later
changing to LGPL if we can).
As for the API I can create start a specialized API for the lib that
uses the internal API.
I can hide BlockDriverState and export it as an fd.
int vdisk_open(path, format, flags)
size_t vdisk_pread(fd, buf, size, offset)
size_t vdisk_pwrite(fd, buff, size, offset)
int vdisk_close(fd)
int vdisk_get_size(fd)
That way no internal structures are exported and we use a minimal set
of functions that are very unlikely to change.
There is no support for snapshots, metadata etc. But these APIs can be
added later.
And of-course we can always define the lib as experimental until the
API stabilizes.
next prev parent reply other threads:[~2011-08-24 11:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-22 17:06 [Qemu-devel] [PATCH 1/2] Better support for distros using lib64 dis Saggi Mizrahi
2011-08-22 17:06 ` [Qemu-devel] [PATCH 2/2] Added target to build libvdisk Saggi Mizrahi
2011-08-22 18:50 ` Blue Swirl
2011-08-22 19:29 ` Anthony Liguori
2011-08-23 16:12 ` Daniel P. Berrange
2011-08-23 16:14 ` Anthony Liguori
2011-08-23 16:18 ` Daniel P. Berrange
2011-08-23 16:21 ` Anthony Liguori
2011-08-24 11:32 ` Saggi Mizrahi [this message]
2011-08-24 12:50 ` Anthony Liguori
2011-08-24 12:55 ` Daniel P. Berrange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E54E140.1060809@redhat.com \
--to=smizrahi@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.