[libvirt] [PATCH 4/5] conf: track more fields in backing chain metadata

Peter Krempa pkrempa at redhat.com
Fri Apr 4 15:07:10 UTC 2014


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140404/f9cd37e1/attachment-0001.sig>


More information about the libvir-list mailing list