On 04/11/2014 08:46 PM, John Ferlan wrote:
On 04/11/2014 12:21 AM, Eric Blake wrote:
> Thanks to the testsuite, I feel quite confident that this rewrite
> still gives the same results for all cases except for one, and
> I can make the argument that _that_ case was a pre-existing bug.
> When looking up relative names, the lookup is supposed to be
> pegged to the directory that contains the parent qcow2 file.
>
> * src/util/virstoragefile.c (virStorageFileChainLookup): Depend on
> new rather than old fields.
> * tests/virstoragetest.c (mymain): Adjust test to match fix.
>
> Signed-off-by: Eric Blake <eblake(a)redhat.com>
> ---
> src/util/virstoragefile.c | 49 +++++++++++++++++++----------------------------
> tests/virstoragetest.c | 3 +--
> 2 files changed, 21 insertions(+), 31 deletions(-)
>
ACK
Although I'll admit I don't know enough about all the backing chain code
to fully understand the "pre-existing" bug comment.
This is the comment I added earlier in the series explaining the
pre-existing bug:
/* FIXME: 21 is questionable, since there is no 'sub/qcow2' and
* since relative backing files should be looked up in the context
* of the directory containing the parent. */
(oops, I already removed the comment in 4/6, even though the bug wasn't
addressed until 5/6). I'll describe it in more detail in the commit
message.
I suppose the only
odd part I found was the comparison < VIR_STORAGE_TYPE_DIR - leaving
currently DIR, NETWORK, and VOLUME out of the comparison. My thoughts
went to what if something new comes along and what on earth was being
compared beforehand...
I think I'll rewrite that to use explicit comparison against
VIR_STORAGE_TYPE_FILE and VIR_STORAGE_TYPE_BLOCK instead.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org