All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: qemu-block@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v3 3/5] block: qobject_is_equal() in bdrv_reopen_prepare()
Date: Wed, 05 Jul 2017 09:14:22 +0200	[thread overview]
Message-ID: <87k23ne4oh.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20170703122505.32017-4-mreitz@redhat.com> (Max Reitz's message of "Mon, 3 Jul 2017 14:25:03 +0200")

Max Reitz <mreitz@redhat.com> writes:

> Currently, bdrv_reopen_prepare() assumes that all BDS options are
> strings. However, this is not the case if the BDS has been created
> through the json: pseudo-protocol or blockdev-add.
>
> Note that the user-invokable reopen command is an HMP command, so you
> can only specify strings there. Therefore, specifying a non-string
> option with the "same" value as it was when originally created will now
> return an error because the values are supposedly similar (and there is
> no way for the user to circumvent this but to just not specify the
> option again -- however, this is still strictly better than just
> crashing).
>
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
>  block.c | 31 ++++++++++++++++++-------------
>  1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/block.c b/block.c
> index 913bb43..45eb248 100644
> --- a/block.c
> +++ b/block.c
> @@ -2947,19 +2947,24 @@ int bdrv_reopen_prepare(BDRVReopenState *reopen_state, BlockReopenQueue *queue,
>          const QDictEntry *entry = qdict_first(reopen_state->options);
>  
>          do {
> -            QString *new_obj = qobject_to_qstring(entry->value);
> -            const char *new = qstring_get_str(new_obj);
> -            /*
> -             * Caution: while qdict_get_try_str() is fine, getting
> -             * non-string types would require more care.  When
> -             * bs->options come from -blockdev or blockdev_add, its
> -             * members are typed according to the QAPI schema, but
> -             * when they come from -drive, they're all QString.
> -             */
> -            const char *old = qdict_get_try_str(reopen_state->bs->options,
> -                                                entry->key);
> -
> -            if (!old || strcmp(new, old)) {
> +            QObject *new = entry->value;
> +            QObject *old = qdict_get(reopen_state->bs->options, entry->key);
> +
> +            /* TODO: When using -drive to specify blockdev options, all values
> +             * will be strings; however, when using -blockdev, blockdev-add or
> +             * filenames using the json:{} pseudo-protocol, they will be
> +             * correctly typed.
> +             * In contrast, reopening options are (currently) always strings
> +             * (because you can only specify them through qemu-io; all other
> +             * callers do not specify any options).
> +             * Therefore, when using anything other than -drive to create a BDS,
> +             * this cannot detect non-string options as unchanged, because
> +             * qobject_is_equal() always returns false for objects of different
> +             * type.  In the future, this should be remedied by correctly typing
> +             * all options.  For now, this is not too big of an issue because
> +             * the user simply can not specify options which cannot be changed
> +             * anyway, so they will stay unchanged. */

I'm not the maintainer, and this is not a demand: consider winging this
comment and wrapping lines around column 70.

As much as I fancy word play (see your reply to Eric), I have to admit
that I had to read "the user simply can not specify options" about three
times to make sense of it.  Please consider a wording that's easier to
grasp, perhaps "the user can simply refrain from specifying options that
cannot be changed".

> +            if (!qobject_is_equal(new, old)) {
>                  error_setg(errp, "Cannot change the option '%s'", entry->key);
>                  ret = -EINVAL;
>                  goto error;

  parent reply	other threads:[~2017-07-05  7:14 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-03 12:25 [Qemu-devel] [PATCH v3 0/5] block: Don't compare strings in bdrv_reopen_prepare() Max Reitz
2017-07-03 12:25 ` [Qemu-devel] [PATCH v3 1/5] qapi/qnull: Add own header Max Reitz
2017-07-03 12:35   ` Eric Blake
2017-07-03 12:25 ` [Qemu-devel] [PATCH v3 2/5] qapi: Add qobject_is_equal() Max Reitz
2017-07-03 12:44   ` Eric Blake
2017-07-05  7:07   ` Markus Armbruster
2017-07-05 13:48     ` Max Reitz
2017-07-05 14:15       ` Eric Blake
2017-07-05 16:11         ` Markus Armbruster
2017-07-05 16:05       ` Max Reitz
2017-07-05 16:22         ` Max Reitz
2017-07-05 16:29           ` Eric Blake
2017-07-05 17:00             ` Max Reitz
2017-07-05 17:04               ` Max Reitz
2017-07-05 17:22                 ` Eric Blake
2017-07-05 17:18               ` Eric Blake
2017-07-05 16:30           ` Max Reitz
2017-07-03 12:25 ` [Qemu-devel] [PATCH v3 3/5] block: qobject_is_equal() in bdrv_reopen_prepare() Max Reitz
2017-07-03 12:51   ` Eric Blake
2017-07-03 13:01     ` Max Reitz
2017-07-03 14:29       ` Eric Blake
2017-07-05  7:14   ` Markus Armbruster [this message]
2017-07-05 17:50     ` Max Reitz
2017-07-03 12:25 ` [Qemu-devel] [PATCH v3 4/5] iotests: Add test for non-string option reopening Max Reitz
2017-07-03 12:25 ` [Qemu-devel] [PATCH v3 5/5] tests: Add check-qobject for equality tests Max Reitz
2017-07-03 14:15   ` Eric Blake
2017-07-03 16:13     ` Max Reitz
2017-07-05  7:22   ` Markus Armbruster

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=87k23ne4oh.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=kwolf@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 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.