On 10/18/2013 11:30 AM, Eric Blake wrote: > This addresses the review from RFCv1 for splitting the glfs checks > to be different from the storage backend checks: > https://www.redhat.com/archives/libvir-list/2013-October/msg00645.html > > I'm still just in RFC stage; wanting to make sure I have the > documentation correct for sample XML prior to actually coding > up the use of <glfs.h> from storage_backend_gluster.c. > > Note that qemu's block/gluster.c documents that qemu expects > that when using glfs to bypass the file system, the image will > always be specified as: > * file=gluster[+transport]://[server[:port]]/volname/image[?socket=...] > which means that there is no way to pass a direct gluster volume > as a raw block device to qemu (it is always a file embedded within > the gluster volume); hence my choice of making a single gluster > volume act as the storage pool. > > Eric Blake (2): > storage: initial support for linking with libgfapi > storage: document gluster pool Another thing to think about while reviewing this: libgfapi is dual-licensed as your choice of LGPLv3+ or GPLv2. That means you cannot copy code from libgfapi into an LGPLv2+ project (only into LGPLv3, GPLv2, GPLv3, or any higher version). Not being a laywer, my interpretation could be off, but http://gplv3.fsf.org/dd3-faq says that as long as you _link_ (and not _copy_) to an LGPLv3 library, you can still release your library/binary as LGPLV2+. But to be on the safe side, it's all the easier to be on the safe side if we limit the use of gfapi to libvirtd (which has been my plan anyways, in case we ever reach the point of shipping storage backends as separate .so files for minimizing dependencies to unused backends). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list