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 <[email protected]> > --- > 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
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
