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