qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: qemu-devel@nongnu.org, eblake@redhat.com,
	Max Reitz <mreitz@redhat.com>,
	qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v14 04/20] qemu-img: Add --share-rw option to subcommands
Date: Fri, 21 Apr 2017 15:25:09 +0200	[thread overview]
Message-ID: <20170421132509.GD4318@noname.redhat.com> (raw)
In-Reply-To: <20170421035606.448-5-famz@redhat.com>

Am 21.04.2017 um 05:55 hat Fam Zheng geschrieben:
> Similar to share-rw qdev property, this will force the opened images to
> allow shared write permission of other programs.
> 
> Signed-off-by: Fam Zheng <famz@redhat.com>

General observation: We were considering to make share-rw require
read-only. Some of the commands converted here always open the image
read-write, so if we go ahead with the restriction, will the option
become useless in many of the subcommands?

>  qemu-img.c | 155 +++++++++++++++++++++++++++++++++++++++++++++++--------------
>  1 file changed, 119 insertions(+), 36 deletions(-)
> 
> diff --git a/qemu-img.c b/qemu-img.c
> index ed24371..df88a79 100644
> --- a/qemu-img.c
> +++ b/qemu-img.c
> @@ -28,6 +28,7 @@
>  #include "qapi/qobject-output-visitor.h"
>  #include "qapi/qmp/qerror.h"
>  #include "qapi/qmp/qjson.h"
> +#include "qapi/qmp/qbool.h"
>  #include "qemu/cutils.h"
>  #include "qemu/config-file.h"
>  #include "qemu/option.h"
> @@ -283,12 +284,15 @@ static int img_open_password(BlockBackend *blk, const char *filename,
>  
>  static BlockBackend *img_open_opts(const char *optstr,
>                                     QemuOpts *opts, int flags, bool writethrough,
> -                                   bool quiet)
> +                                   bool quiet, bool share_rw)
>  {
>      QDict *options;
>      Error *local_err = NULL;
>      BlockBackend *blk;
>      options = qemu_opts_to_qdict(opts, NULL);
> +    if (share_rw) {
> +        qdict_put(options, BDRV_OPT_FORCE_SHARED_WRITE, qbool_from_bool(true));
> +    }

It's interesting that you chose a conditional qdict_put for true rather
than an unconditional one for share_rw here. The difference becomes
visible when someone sets both -U and share-rw=off; we need to decide
which one should take precedence.

Generally, we always give explicit options the precedence, so if we were
to follow suit here, we would set share-rw here only if the option isn't
already set. For strings, we have qdict_set_default_str() to achieve
this, for bools we probably need a new function (or does Eric's series
which introduces qdict_put_bool() also introduce a similar function,
like some qdict_set_default_bool?)

>      blk = blk_new_open(NULL, NULL, options, flags, &local_err);
>      if (!blk) {
>          error_reportf_err(local_err, "Could not open '%s': ", optstr);

> @@ -2985,6 +3035,7 @@ static int img_rebase(int argc, char **argv)
>      int c, flags, src_flags, ret;
>      bool writethrough, src_writethrough;
>      int unsafe = 0;
> +    bool share_rw = 0;

Not false?

>      int progress = 0;
>      bool quiet = false;
>      Error *local_err = NULL;
> @@ -3001,9 +3052,10 @@ static int img_rebase(int argc, char **argv)
>              {"help", no_argument, 0, 'h'},
>              {"object", required_argument, 0, OPTION_OBJECT},
>              {"image-opts", no_argument, 0, OPTION_IMAGE_OPTS},
> +            {"share-rw", no_argument, 0, 'U'},
>              {0, 0, 0, 0}
>          };
> -        c = getopt_long(argc, argv, ":hf:F:b:upt:T:q",
> +        c = getopt_long(argc, argv, ":hf:F:b:upt:T:qU",
>                          long_options, NULL);
>          if (c == -1) {
>              break;
> @@ -3053,6 +3105,9 @@ static int img_rebase(int argc, char **argv)
>          case OPTION_IMAGE_OPTS:
>              image_opts = true;
>              break;
> +        case 'U':
> +            share_rw = true;
> +            break;
>          }
>      }
>  
> @@ -3101,7 +3156,8 @@ static int img_rebase(int argc, char **argv)
>       * Ignore the old backing file for unsafe rebase in case we want to correct
>       * the reference to a renamed or moved backing file.
>       */
> -    blk = img_open(image_opts, filename, fmt, flags, writethrough, quiet);
> +    blk = img_open(image_opts, filename, fmt, flags, writethrough, quiet,
> +                   share_rw);
>      if (!blk) {
>          ret = -1;
>          goto out;
> @@ -3126,6 +3182,9 @@ static int img_rebase(int argc, char **argv)
>              qdict_put(options, "driver", qstring_from_str(bs->backing_format));
>          }
>  
> +        if (share_rw) {
> +            qdict_put(options, BDRV_OPT_FORCE_SHARED_WRITE, qbool_from_bool(true));

This is longer than 80 lines and wrapping wouldn't make it unreadable. I
think there are more similar instances in this series (even though you
replied to the patchew mail that they are intentional).

> +        }
>          bdrv_get_backing_filename(bs, backing_name, sizeof(backing_name));
>          blk_old_backing = blk_new_open(backing_name, NULL,
>                                         options, src_flags, &local_err);

Why don't you apply share_rw to blk_new_backing, which is opened a few
lines down from here?

Kevin

  reply	other threads:[~2017-04-21 13:25 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21  3:55 [Qemu-devel] [PATCH v14 00/20] block: Image locking series Fam Zheng
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 01/20] block: Add, parse and store "force-shared-write" option Fam Zheng
2017-04-21  8:34   ` Kevin Wolf
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 02/20] qapi: Add 'force-shared-write' to blockdev-add arguments Fam Zheng
2017-04-21  8:35   ` Kevin Wolf
2017-04-21  8:42     ` Fam Zheng
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 03/20] block: Respect "force-shared-write" in perm propagating Fam Zheng
2017-04-21  8:38   ` Kevin Wolf
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 04/20] qemu-img: Add --share-rw option to subcommands Fam Zheng
2017-04-21 13:25   ` Kevin Wolf [this message]
2017-04-21 15:35     ` Eric Blake
2017-04-24  6:10     ` Fam Zheng
2017-04-24 10:13       ` Kevin Wolf
2017-04-24 11:28         ` Fam Zheng
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 05/20] qemu-img: Update documentation for --share-rw Fam Zheng
2017-04-21 15:37   ` Eric Blake
2017-04-24  5:44     ` Fam Zheng
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 06/20] qemu-io: Add --share-rw option Fam Zheng
2017-04-21 13:45   ` Kevin Wolf
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 07/20] iotests: 030: Prepare for image locking Fam Zheng
2017-04-21 13:51   ` Kevin Wolf
2017-04-24  6:15     ` Fam Zheng
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 08/20] iotests: 046: " Fam Zheng
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 09/20] iotests: 055: Don't attach the target image already for drive-backup Fam Zheng
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 10/20] iotests: 085: Avoid image locking conflict Fam Zheng
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 11/20] iotests: 087: Don't attach test image twice Fam Zheng
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 12/20] iotests: 091: Quit QEMU before checking image Fam Zheng
2017-04-21  3:55 ` [Qemu-devel] [PATCH v14 13/20] iotests: 172: Use separate images for multiple devices Fam Zheng
2017-04-21  3:56 ` [Qemu-devel] [PATCH v14 14/20] tests: Use null-co:// instead of /dev/null as the dummy image Fam Zheng
2017-04-21  3:56 ` [Qemu-devel] [PATCH v14 15/20] file-posix: Add 'locking' option Fam Zheng
2017-04-21  3:56 ` [Qemu-devel] [PATCH v14 16/20] tests: Disable image lock in test-replication Fam Zheng
2017-04-21  3:56 ` [Qemu-devel] [PATCH v14 17/20] block: Reuse bs as backing hd for drive-backup sync=none Fam Zheng
2017-04-21  3:56 ` [Qemu-devel] [PATCH v14 18/20] osdep: Add qemu_lock_fd and qemu_unlock_fd Fam Zheng
2017-04-21  3:56 ` [Qemu-devel] [PATCH v14 19/20] file-posix: Add image locking in perm operations Fam Zheng
2017-04-24 13:39   ` Kevin Wolf
2017-04-21  3:56 ` [Qemu-devel] [PATCH v14 20/20] qemu-iotests: Add test case 153 for image locking Fam Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170421132509.GD4318@noname.redhat.com \
    --to=kwolf@redhat.com \
    --cc=eblake@redhat.com \
    --cc=famz@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).