qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 0/6] block: Relative backing files


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH v4 0/6] block: Relative backing files
Date: Mon, 15 Dec 2014 10:44:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 2014-11-26 at 17:20, Max Reitz wrote:
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 (with patch numbers fixed):

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 5 of this v2 (v4) 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 4.

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 2. Patch 3 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 6 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).


v4:
- Added patch 1: Patch 3 (prev. 2) failed checkpatch.pl, so do the
   obvious: Fix checkpatch.pl.
- Patch 3 (prev. 2): Fix overly long line [Fam]
- Patch 6 (prev. 5): s/shoud/should/ [Eric]


git-backport-diff against v3:

Key:
[----] : patches are identical
[####] : number of functional differences between upstream/downstream patch
[down] : patch is downstream-only
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively

001/6:[down] 'checkpatch: Brace handling on multi-line condition'
002/6:[----] [--] 'block: Get full backing filename from string'
003/6:[0003] [FC] 'block: JSON filenames and relative backing files'
004/6:[----] [--] 'block: Relative backing file for image creation'
005/6:[----] [--] 'block/vmdk: Relative backing file for creation'
006/6:[0002] [FC] 'iotests: Add test for relative backing file names'


Max Reitz (6):
   checkpatch: Brace handling on multi-line condition
   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                    | 46 ++++++++++++++++++++---
  block/qapi.c               |  7 +++-
  block/vmdk.c               | 13 ++++++-
  include/block/block.h      |  6 ++-
  scripts/checkpatch.pl      | 13 ++++++-
  tests/qemu-iotests/110     | 94 ++++++++++++++++++++++++++++++++++++++++++++++
  tests/qemu-iotests/110.out | 19 ++++++++++
  tests/qemu-iotests/group   |  1 +
  8 files changed, 188 insertions(+), 11 deletions(-)
  create mode 100755 tests/qemu-iotests/110
  create mode 100644 tests/qemu-iotests/110.out

Ping



reply via email to

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