qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH v3 0/5] block: Relative backing files


From: Max Reitz
Subject: [Qemu-devel] [PATCH v3 0/5] block: Relative backing files
Date: Mon, 24 Nov 2014 10:43:15 +0100

Cover letter of v1:

Sometimes, qemu does not have a filename to work with (it then generates
a JSON filename), so it does not know which directory to use for a
backing file specified by a relative filename.

In this case, qemu should not somehow try to append the backing file's
name to the JSON object, but rather just print an error and bail out.


Part of the cover letter specific to v2:

Stefan already applied v1 before realizing that the test added in the
series was actually broken for vmdk (which I somehow missed myself).
This was due to vmdk trying to open the backing file on creation in
order to determine its format; however, normally the backing file path
is interpreted relatively to the backed image's base directory, whereas
in this case vmdk directly used the user-specified filename which was
therefore interpreted relatively to qemu's working directory.

Patch 4 of this v2 fixes this. A similar issue exists directly in
bdrv_img_create() which opens the backing file in order to determine its
size in case the size of the new image has not been specified. This is
fixed by patch 3.

The function both patches use is factored out from
bdrv_get_full_backing_filename() (which we cannot use here because it
requires a BDS which does not necessarily exist during image creation)
in patch 1. Patch 2 was then modified so it modifies this new function
(bdrv_get_full_backing_filename_from_filename()) and the old
bdrv_get_full_backing_filename(), which is now more or less just a
wrapper.

And finally, I added a test to patch 5 which tests creation of a backed
image in another directory only using relative paths while omitting the
image size (which is therefore inferred from the backing file).


v3:
- Solved merge conflict in the iotests group file [Kevin]
  (On a note unrelated to this series: I'm not sure patches should be
  stopped due to merge conflicts in that file. That would mean only one
  patch per week creating a new iotest, and I don't think that limit is
  necessary. Conflicts in that file can be easily resolved (it's even
  clear how to resolve issues when the test number is already taken, but
  that's a different story).)
  This series now applies to Kevin's and mine block-next, block and to
  master.


Max Reitz (5):
  block: Get full backing filename from string
  block: JSON filenames and relative backing files
  block: Relative backing file for image creation
  block/vmdk: Relative backing file for creation
  iotests: Add test for relative backing file names

 block.c                    | 45 +++++++++++++++++++---
 block/qapi.c               |  7 +++-
 block/vmdk.c               | 13 ++++++-
 include/block/block.h      |  6 ++-
 tests/qemu-iotests/110     | 94 ++++++++++++++++++++++++++++++++++++++++++++++
 tests/qemu-iotests/110.out | 19 ++++++++++
 tests/qemu-iotests/group   |  1 +
 7 files changed, 176 insertions(+), 9 deletions(-)
 create mode 100755 tests/qemu-iotests/110
 create mode 100644 tests/qemu-iotests/110.out

-- 
1.9.3




reply via email to

[Prev in Thread] Current Thread [Next in Thread]