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@redhat.com> --- 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