From: Max Reitz <mreitz@redhat.com>
To: qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
Kevin Wolf <kwolf@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: [Qemu-devel] [RFC 0/7] block: Try to use correctly typed blockdev options
Date: Wed, 2 May 2018 23:32:12 +0200 [thread overview]
Message-ID: <20180502213219.7842-1-mreitz@redhat.com> (raw)
(Sorry, Markus, sorry, Kevin, if this series makes you angry.)
The subject says it all, I think. The original issue I was assigned to
solve is this:
$ ./qemu-img info --image-opts driver=null-co,size=42
image: json:{"driver": "null-co", "size": "42"}
[...]
As you can see, "size" gets a string value in the json:{} object
although it is an integer, according to the QAPI schema. (Buglink:
https://bugzilla.redhat.com/show_bug.cgi?id=1534396)
My first approach to fix this was to try to pipe the full_open_options
dict generated in bdrv_refresh_filename() through a keyval input visitor
and then an output visitor (which would have depended on my filename
series). This did not work out because bs->options (where all of the
reconstructed options come from) may either be correctly typed or not,
and keyval chokes on non-string values. I could have probably converted
bs->options to fully string values before trying to pipe it through
keyval, but I decided I didn't like that very much. (I suppose I can be
convinced otherwise, though.)
So I decided to venture into the territory of what we actually want at
some point: Correctly typed bs->options. Or, rather, in the end we want
bs->options to be BlockdevOptions, but let's not be too hasty here.
So it turns out that with really just a bit of work we can separate the
interfaces that generate correctly typed options (e.g. blockdev-add)
from the ones that generate pure string-valued options (e.g. qemu-img
--image-opts) rather well. Once we have done that, we can pipe all of
the pure string options through keyval and back to get correctly typed
options.
So far the theory. Now, in practice we of course have pitfalls, and
those are not addressed by this series, which is the main reason this is
an RFC.
The first pitfall (I can see...) is that json:{} allows you to specify
mixed options -- some values are incorrectly strings, others are
non-strings. keyval cannot cope with that, so the result after this
series is that those options end up in bs->options just like that. I
suppose we could just forbid that mixed-typed case, though, and call it
a bug fix.
The second problem (and I think the big reason why we have not
approached this issue so far) is that there are options which you can
give as strings, but which are not covered by the schema. In such a
case, the input visitor will reject the QDict and we will just use it
as-is, that is, full of strings. Now that is not what we want in the
end, of course -- we want everything to be converted into something that
is covered by the schema.
My reasoning for sending this series anyway is that it doesn't make
things worse (bs->options is a mess already, you can never be certain
that it contains correctly typed values or just strings or both), and
that it at least gives a starting point from which we can continue on.
After this series, we have a clear separation between the interfaces
that use purely string values and the ones that provide correct typing
(well, and json:{}).
Oh, and it fixes the above BZ for the more common cases.
Max Reitz (7):
qdict: Add qdict_set_default_bool()
block: Let change-medium add detect-zeroes as bool
block: Make use of qdict_set_default_bool()
block: Add bdrv_open_string_opts()
block: Add blk_new_open_string_opts()
block: Use {blk_new,bdrv}_open_string_opts()
iotests: Test internal option typing
include/block/block.h | 2 +
include/qapi/qmp/qdict.h | 1 +
include/sysemu/block-backend.h | 2 +
block.c | 96 ++++++++++++++++++++++++++++++++++++++----
block/block-backend.c | 30 ++++++++++++-
block/vvfat.c | 4 +-
blockdev.c | 33 ++++++++++-----
qemu-img.c | 3 +-
qemu-io.c | 2 +-
qemu-nbd.c | 2 +-
qobject/qdict.c | 13 ++++++
tests/test-replication.c | 6 +--
tests/qemu-iotests/089 | 12 ++++++
tests/qemu-iotests/089.out | 5 +++
14 files changed, 183 insertions(+), 28 deletions(-)
--
2.14.3
next reply other threads:[~2018-05-02 21:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-02 21:32 Max Reitz [this message]
2018-05-02 21:32 ` [Qemu-devel] [RFC 1/7] qdict: Add qdict_set_default_bool() Max Reitz
2018-05-02 21:32 ` [Qemu-devel] [RFC 2/7] block: Let change-medium add detect-zeroes as bool Max Reitz
2018-05-02 21:32 ` [Qemu-devel] [RFC 3/7] block: Make use of qdict_set_default_bool() Max Reitz
2018-05-02 21:32 ` [Qemu-devel] [RFC 4/7] block: Add bdrv_open_string_opts() Max Reitz
2018-05-02 21:32 ` [Qemu-devel] [RFC 5/7] block: Add blk_new_open_string_opts() Max Reitz
2018-05-02 21:32 ` [Qemu-devel] [RFC 6/7] block: Use {blk_new, bdrv}_open_string_opts() Max Reitz
2018-05-02 21:32 ` [Qemu-devel] [RFC 7/7] iotests: Test internal option typing Max Reitz
2018-05-02 21:36 ` [Qemu-devel] [Qemu-block] [RFC 0/7] block: Try to use correctly typed blockdev options Max Reitz
2018-05-03 8:16 ` [Qemu-devel] " Markus Armbruster
2018-05-04 15:53 ` Max Reitz
2018-05-04 16:11 ` Max Reitz
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=20180502213219.7842-1-mreitz@redhat.com \
--to=mreitz@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@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).