qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/2] Added target to build libvdisk


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 2/2] Added target to build libvdisk
Date: Wed, 24 Aug 2011 07:50:37 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 08/24/2011 06:32 AM, Saggi Mizrahi wrote:
On Tue 23 Aug 2011 07:21:56 PM IDT, Anthony Liguori wrote:
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's not really much better. You'll only end up reinventing the block layer API.

The best route is to focus on cleaning up the block layer interface. This means converting existing users to use a single interface, adding documentation to each interface, writing test cases against the block layer API.

Practically speaking, I think we really need to move the block layer to use glib primitives too before you can realistically consume the code outside of QEMU.

Regards,

Anthony Liguori


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.





reply via email to

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