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
next prev parent 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).