All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH v2] qemu-img: Clarify about relative backing file options
@ 2017-08-04 14:36 Fam Zheng
  2017-08-04 14:42 ` Eric Blake
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Fam Zheng @ 2017-08-04 14:36 UTC (permalink / raw)
  To: qemu-devel; +Cc: Eric Blake, Kevin Wolf, Max Reitz, qemu-block

It's not too surprising when a user specifies the backing file relative
to the current working directory instead of the top layer image. This
causes error when they differ. Though the error message has enough
information to infer the fact about the misunderstanding, it is better
if we document this explicitly, so that users don't have to learn from
mistakes.

Signed-off-by: Fam Zheng <famz@redhat.com>

---
v2: Improve wording. [Eric]
---
 qemu-img.texi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/qemu-img.texi b/qemu-img.texi
index 72dabd6b3e..90c7eab4a8 100644
--- a/qemu-img.texi
+++ b/qemu-img.texi
@@ -244,6 +244,9 @@ only the differences from @var{backing_file}. No size needs to be specified in
 this case. @var{backing_file} will never be modified unless you use the
 @code{commit} monitor command (or qemu-img commit).
 
+If a relative path name is given, the backing file is looked up relative to
+the directory containing @var{filename}.
+
 Note that a given backing file will be opened to check that it is valid. Use
 the @code{-u} option to enable unsafe backing file mode, which means that the
 image will be created even if the associated backing file cannot be opened. A
@@ -343,6 +346,9 @@ created as a copy on write image of the specified base image; the
 @var{backing_file} should have the same content as the input's base image,
 however the path, image format, etc may differ.
 
+If a relative path name is given, the backing file is looked up relative to
+the directory containing @var{output_filename}.
+
 If the @code{-n} option is specified, the target volume creation will be
 skipped. This is useful for formats such as @code{rbd} if the target
 volume has already been created with site specific options that cannot
@@ -490,6 +496,9 @@ The backing file is changed to @var{backing_file} and (if the image format of
 string), then the image is rebased onto no backing file (i.e. it will exist
 independently of any backing file).
 
+If a relative path name is given, the backing file is looked up relative to
+the directory containing @var{filename}.
+
 @var{cache} specifies the cache mode to be used for @var{filename}, whereas
 @var{src_cache} specifies the cache mode for reading backing files.
 
-- 
2.13.3

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH v2] qemu-img: Clarify about relative backing file options
  2017-08-04 14:36 [Qemu-devel] [PATCH v2] qemu-img: Clarify about relative backing file options Fam Zheng
@ 2017-08-04 14:42 ` Eric Blake
  2017-08-04 15:14 ` [Qemu-devel] [Qemu-block] " Jeff Cody
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Eric Blake @ 2017-08-04 14:42 UTC (permalink / raw)
  To: Fam Zheng, qemu-devel; +Cc: Kevin Wolf, Max Reitz, qemu-block

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

On 08/04/2017 09:36 AM, Fam Zheng wrote:
> It's not too surprising when a user specifies the backing file relative
> to the current working directory instead of the top layer image. This
> causes error when they differ. Though the error message has enough
> information to infer the fact about the misunderstanding, it is better
> if we document this explicitly, so that users don't have to learn from
> mistakes.
> 
> Signed-off-by: Fam Zheng <famz@redhat.com>
> 
> ---
> v2: Improve wording. [Eric]
> ---
>  qemu-img.texi | 9 +++++++++
>  1 file changed, 9 insertions(+)

Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [Qemu-block] [PATCH v2] qemu-img: Clarify about relative backing file options
  2017-08-04 14:36 [Qemu-devel] [PATCH v2] qemu-img: Clarify about relative backing file options Fam Zheng
  2017-08-04 14:42 ` Eric Blake
@ 2017-08-04 15:14 ` Jeff Cody
  2017-08-08 10:14 ` Stefan Hajnoczi
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Jeff Cody @ 2017-08-04 15:14 UTC (permalink / raw)
  To: Fam Zheng; +Cc: qemu-devel, Kevin Wolf, qemu-block, Max Reitz

On Fri, Aug 04, 2017 at 10:36:58PM +0800, Fam Zheng wrote:
> It's not too surprising when a user specifies the backing file relative
> to the current working directory instead of the top layer image. This
> causes error when they differ. Though the error message has enough
> information to infer the fact about the misunderstanding, it is better
> if we document this explicitly, so that users don't have to learn from
> mistakes.
> 
> Signed-off-by: Fam Zheng <famz@redhat.com>
> 
> ---
> v2: Improve wording. [Eric]
> ---
>  qemu-img.texi | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/qemu-img.texi b/qemu-img.texi
> index 72dabd6b3e..90c7eab4a8 100644
> --- a/qemu-img.texi
> +++ b/qemu-img.texi
> @@ -244,6 +244,9 @@ only the differences from @var{backing_file}. No size needs to be specified in
>  this case. @var{backing_file} will never be modified unless you use the
>  @code{commit} monitor command (or qemu-img commit).
>  
> +If a relative path name is given, the backing file is looked up relative to
> +the directory containing @var{filename}.
> +
>  Note that a given backing file will be opened to check that it is valid. Use
>  the @code{-u} option to enable unsafe backing file mode, which means that the
>  image will be created even if the associated backing file cannot be opened. A
> @@ -343,6 +346,9 @@ created as a copy on write image of the specified base image; the
>  @var{backing_file} should have the same content as the input's base image,
>  however the path, image format, etc may differ.
>  
> +If a relative path name is given, the backing file is looked up relative to
> +the directory containing @var{output_filename}.
> +
>  If the @code{-n} option is specified, the target volume creation will be
>  skipped. This is useful for formats such as @code{rbd} if the target
>  volume has already been created with site specific options that cannot
> @@ -490,6 +496,9 @@ The backing file is changed to @var{backing_file} and (if the image format of
>  string), then the image is rebased onto no backing file (i.e. it will exist
>  independently of any backing file).
>  
> +If a relative path name is given, the backing file is looked up relative to
> +the directory containing @var{filename}.
> +
>  @var{cache} specifies the cache mode to be used for @var{filename}, whereas
>  @var{src_cache} specifies the cache mode for reading backing files.
>  
> -- 
> 2.13.3
> 
> 

Reviewed-by: Jeff Cody <jcody@redhat.com>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [Qemu-block] [PATCH v2] qemu-img: Clarify about relative backing file options
  2017-08-04 14:36 [Qemu-devel] [PATCH v2] qemu-img: Clarify about relative backing file options Fam Zheng
  2017-08-04 14:42 ` Eric Blake
  2017-08-04 15:14 ` [Qemu-devel] [Qemu-block] " Jeff Cody
@ 2017-08-08 10:14 ` Stefan Hajnoczi
  2017-08-31  6:52 ` [Qemu-devel] " Fam Zheng
  2017-09-07 15:11 ` Kevin Wolf
  4 siblings, 0 replies; 6+ messages in thread
From: Stefan Hajnoczi @ 2017-08-08 10:14 UTC (permalink / raw)
  To: Fam Zheng; +Cc: qemu-devel, Kevin Wolf, qemu-block, Max Reitz

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

On Fri, Aug 04, 2017 at 10:36:58PM +0800, Fam Zheng wrote:
> It's not too surprising when a user specifies the backing file relative
> to the current working directory instead of the top layer image. This
> causes error when they differ. Though the error message has enough
> information to infer the fact about the misunderstanding, it is better
> if we document this explicitly, so that users don't have to learn from
> mistakes.
> 
> Signed-off-by: Fam Zheng <famz@redhat.com>
> 
> ---
> v2: Improve wording. [Eric]
> ---
>  qemu-img.texi | 9 +++++++++
>  1 file changed, 9 insertions(+)

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH v2] qemu-img: Clarify about relative backing file options
  2017-08-04 14:36 [Qemu-devel] [PATCH v2] qemu-img: Clarify about relative backing file options Fam Zheng
                   ` (2 preceding siblings ...)
  2017-08-08 10:14 ` Stefan Hajnoczi
@ 2017-08-31  6:52 ` Fam Zheng
  2017-09-07 15:11 ` Kevin Wolf
  4 siblings, 0 replies; 6+ messages in thread
From: Fam Zheng @ 2017-08-31  6:52 UTC (permalink / raw)
  To: qemu-devel; +Cc: Kevin Wolf, qemu-block, Max Reitz

On Fri, 08/04 22:36, Fam Zheng wrote:
> It's not too surprising when a user specifies the backing file relative
> to the current working directory instead of the top layer image. This
> causes error when they differ. Though the error message has enough
> information to infer the fact about the misunderstanding, it is better
> if we document this explicitly, so that users don't have to learn from
> mistakes.

Gentle ping as a reminder for 2.11, as 2.10 is now out of door.

Fam

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [PATCH v2] qemu-img: Clarify about relative backing file options
  2017-08-04 14:36 [Qemu-devel] [PATCH v2] qemu-img: Clarify about relative backing file options Fam Zheng
                   ` (3 preceding siblings ...)
  2017-08-31  6:52 ` [Qemu-devel] " Fam Zheng
@ 2017-09-07 15:11 ` Kevin Wolf
  4 siblings, 0 replies; 6+ messages in thread
From: Kevin Wolf @ 2017-09-07 15:11 UTC (permalink / raw)
  To: Fam Zheng; +Cc: qemu-devel, Eric Blake, Max Reitz, qemu-block

Am 04.08.2017 um 16:36 hat Fam Zheng geschrieben:
> It's not too surprising when a user specifies the backing file relative
> to the current working directory instead of the top layer image. This
> causes error when they differ. Though the error message has enough
> information to infer the fact about the misunderstanding, it is better
> if we document this explicitly, so that users don't have to learn from
> mistakes.
> 
> Signed-off-by: Fam Zheng <famz@redhat.com>

Thanks, applied to the block branch.

Kevin

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-09-07 15:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-04 14:36 [Qemu-devel] [PATCH v2] qemu-img: Clarify about relative backing file options Fam Zheng
2017-08-04 14:42 ` Eric Blake
2017-08-04 15:14 ` [Qemu-devel] [Qemu-block] " Jeff Cody
2017-08-08 10:14 ` Stefan Hajnoczi
2017-08-31  6:52 ` [Qemu-devel] " Fam Zheng
2017-09-07 15:11 ` Kevin Wolf

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.