On 04/04/14 14:54, Eric Blake wrote:
On 04/04/2014 03:31 AM, Peter Krempa wrote:
>> struct _virStorageFileMetadata {
>> - char *backingStore; /* Canonical name (absolute file, or protocol) */
>> - char *backingStoreRaw; /* If file, original name, possibly relative */
>> - char *directory; /* The directory containing basename of backingStoreRaw */
>> - int backingStoreFormat; /* enum virStorageFileFormat */
>> - bool backingStoreIsFile;
>> + /* Name of this file as spelled by the user (top level) or
>> + * metadata of the parent (if this is a backing store). */
>> + char *path;
>> + /* Canonical name of this file, used to detect loops in the
>> + * backing store chain. */
>> + char *canonName;
>> + /* Directory to start from if backingStoreRaw is a relative file
>> + * name */
>> + char *relDir;
>> + /* Name of the backing store recorded in metadata of the parent */
Maybe then change "parent" to "this image" to un-confuse me :)
>> + char *backingStoreRaw;
>
> Hmm, this field seems pretty redundant to me, IIUC it's the same data as
> in "path".
No, it's not.
Given the chain:
base <- top
my goal is to have:
{ .path = "top",
.canonName = "/path/to/top",
.relDir = ".",
.backingStoreRaw = "base",
.backingMeta = {
.path = "base",
.canonName = "/path/to/base",
.relDir = ".",
.backingStoreRaw = NULL,
.backingMeta = NULL,
}
}
....
my mind was poisoned with the current way the code is filling the fields
and a little bit with the comment.
ACK the refactor makes sense. Maybe it's worth changing the wording a
bit though.
Peter