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

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Aug 24, 2011 at 07:50:37AM -0500, Anthony Liguori wrote:
> 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.

I think it'd be interesting to ask what the intended use cases for
accessing the block layer API outside of QEMU are ?

Personally, for libvirt, I'm only interested in a libblkid like library
that lets us detect what format a disk is, and query some basic metadata
about the file (logical size, vs physical size, backing file paths,
backing file format, whether encryption is present, etc - qemu-img info
equivalent basically).

Apps that actually want to read/write the contents of a virtual disk,
may well be better off just using libguestfs as the API, since they
may well want to actually interpret the data inside the disk, eg to
read specific files out of the filesystem, etc

There's possibly a need for a API to create/clone/convert virtual
disks formats, but that could likely be done without directly
exposing apps to any of the low level BlockDrv APis like pread/pwrite,
instead providing an API at the level of 'qemu-img create' command
args.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|