On 04/17/2014 04:20 AM, Martin Kletzander wrote: > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1019926 > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=868673 > > Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx> > --- > src/libvirt_private.syms | 2 +- > src/qemu/qemu_domain.c | 3 +++ > src/util/virstoragefile.c | 15 +++++++++++++++ > src/util/virstoragefile.h | 2 ++ > 4 files changed, 21 insertions(+), 1 deletion(-) > @@ -1850,7 +1851,6 @@ virStorageSourcePoolModeTypeToString; > virStorageTypeFromString; > virStorageTypeToString; > > - > # util/virstring.h Spurious whitespace change. > + > +bool > +virStorageFormatMaySupportSnapshots(enum virStorageFileFormat format) > +{ > + if (format == VIR_STORAGE_FILE_AUTO || > + format == VIR_STORAGE_FILE_AUTO_SAFE) > + return true; > + > + /* Better safe than sorry */ > + if (format <= VIR_STORAGE_FILE_NONE || > + format >= VIR_STORAGE_FILE_LAST) > + return false; > + > + return !!fileTypeInfo[format].getBackingStore; Hmm, how does this compare with the recent commit db7d7c0e which added the VIR_STORAGE_FILE_BACKING marker? I made that separation in order to state that all formats less than the marker do not have a getBackingStore callback (well, other than the exceptions of the _AUTO and _AUTO_SAFE formats which are less than 0), and all formats >= that marker DO have a potential for a backing store. Should this code be using that new constant instead of probing the existence of getBackingStore? Or conversely, should the domain_conf.c code that I touched in that patch instead be using this new function instead of relying on the VIR_STORAGE_FILE_BACKING marker? -- 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