On 04/20/2014 04:13 PM, Peter Krempa wrote:
> Remove the obsolete field replaced by data in "path".
>
> The testsuite requires tweaking as the name of the backing file is now
> stored one layer deeper in the backking chain linked list.
s/backking/backing/
> ---
> src/conf/domain_conf.c | 13 ++++++------
> src/qemu/qemu_driver.c | 8 ++++----
> src/util/virstoragefile.c | 5 -----
> src/util/virstoragefile.h | 5 -----
> tests/virstoragetest.c | 50 +++++++++++++++++++++++------------------------
> 5 files changed, 36 insertions(+), 45 deletions(-)
>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 05fa3f9..006aa96 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -18565,16 +18565,17 @@ virDomainDiskDefForeachPath(virDomainDiskDefPtr disk,
>
> if (iter(disk, path, 0, opaque) < 0)
> goto cleanup;
> -
> - tmp = disk->backingChain;
> - while (tmp && virStorageIsFile(tmp->backingStore)) {
> - if (!ignoreOpenFailure && !tmp->backingMeta) {
> + /* XXX: temporarily we need to select the second element of the backing
> + * chain to start as the first is the copy of the disk itself. */
> + tmp = disk->backingChain ? disk->backingChain->backingMeta : NULL;
> + while (tmp && virStorageIsFile(tmp->path)) {
For that matter, if a future patch allows a file to be the backing store
of a network path, we don't want to stop the iteration just because
there was nothing to label on the intermediate network resource. So
this isn't the last time we will be touching this function :)
> +++ b/src/util/virstoragefile.h
> @@ -148,11 +148,6 @@ struct _virStorageFileMetadata {
> unsigned long long capacity;
> virBitmapPtr features; /* bits described by enum virStorageFileFeature */
> char *compat;
> -
> - /* Fields I'm trying to delete, because it is confusing to have to
> - * query the parent metadata for details about the backing
> - * store. */
> - char *backingStore; /* Canonical name (absolute file, or protocol). Should be same as backingMeta->canonPath */
> };
Yay - you finished the efforts I started. The fact that you were able
to pick up where I left off is reassuring - it means the design is
indeed progressing to something a bit more reasonable to understand, and
that I explained my goals fairly well.
ACK.
--
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