From: Kevin Wolf <kwolf@redhat.com>
To: Alberto Garcia <berto@igalia.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 09/13] block: Add 'runtime_opts' and 'mutable_opts' fields to BlockDriver
Date: Fri, 1 Mar 2019 15:18:09 +0100 [thread overview]
Message-ID: <20190301141809.GD5861@localhost.localdomain> (raw)
In-Reply-To: <w51tvgm7nim.fsf@maestria.local.igalia.com>
Am 01.03.2019 um 14:05 hat Alberto Garcia geschrieben:
> On Fri 01 Mar 2019 01:56:42 PM CET, Kevin Wolf wrote:
> >> >> >> diff --git a/include/block/block_int.h b/include/block/block_int.h
> >> >> >> index fd0e88d17a..e680dda86b 100644
> >> >> >> --- a/include/block/block_int.h
> >> >> >> +++ b/include/block/block_int.h
> >> >> >> @@ -345,6 +345,13 @@ struct BlockDriver {
> >> >> >>
> >> >> >> /* List of options for creating images, terminated by name == NULL */
> >> >> >> QemuOptsList *create_opts;
> >> >> >> + /* Runtime options for a block device, terminated by name == NULL */
> >> >> >> + QemuOptsList *runtime_opts;
> >> >> >
> >> >> > I'm not sure if using a QemuOptsList here is a good idea. Currently,
> >> >> > we use QemuOptsLists for most options, but there are some drivers that
> >> >> > use it only for part of their options, or not at all, using direct
> >> >> > QDict accesses or QAPI objects for the rest.
> >> >>
> >> >> My intention was to avoid having two separate lists with the runtime
> >> >> options of a driver. For this feature we really need that list to
> >> >> contain all options, otherwise there's no way to know whether a missing
> >> >> option is really missing or if it doesn't exist in the first place.
> >> >
> >> > Yes, I understand your intention and the requirement. My point is just
> >> > that the existing QemuOptsLists are often _not_ complete, so they
> >> > can't fulfill the requirement.
> >>
> >> Perhaps a new data structure with a list of runtime options and whether
> >> they can be resetted to their default value or not.
> >
> > Basically just an array that contains names and bools, right? I think
> > that would work.
>
> Yes exactly. My concern is that the array has to be updated by hand
> every time a new option is added to the driver, so they could easily be
> out of sync.
Hm, actually, do you even need the runtime_opts list?
You use it in bdrv_reset_options_allowed() to iterate through each
option and then check whether it was present in the old set of options,
but not in the new set of options.
In order to achieve this, you can just iterate the old options dict
because you don't do anything with options that are present in the
QemuOptsList, but not the old options dict.
Kevin
next prev parent reply other threads:[~2019-03-01 14:33 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-17 15:33 [Qemu-devel] [PATCH 00/13] Add a 'x-blockdev-reopen' QMP command Alberto Garcia
2019-01-17 15:33 ` [Qemu-devel] [PATCH 01/13] block: Allow freezing BdrvChild links Alberto Garcia
2019-02-12 14:47 ` Kevin Wolf
2019-02-14 14:13 ` Alberto Garcia
2019-02-14 15:52 ` Kevin Wolf
2019-02-18 13:35 ` Alberto Garcia
2019-01-17 15:33 ` [Qemu-devel] [PATCH 02/13] block: Freeze the backing chain for the duration of the commit job Alberto Garcia
2019-02-12 14:54 ` Kevin Wolf
2019-02-14 15:21 ` Alberto Garcia
2019-02-14 15:45 ` Kevin Wolf
2019-01-17 15:33 ` [Qemu-devel] [PATCH 03/13] block: Freeze the backing chain for the duration of the mirror job Alberto Garcia
2019-01-17 15:33 ` [Qemu-devel] [PATCH 04/13] block: Freeze the backing chain for the duration of the stream job Alberto Garcia
2019-02-12 15:15 ` Kevin Wolf
2019-02-12 16:06 ` Alberto Garcia
2019-01-17 15:33 ` [Qemu-devel] [PATCH 05/13] block: Add 'keep_old_opts' parameter to bdrv_reopen_queue() Alberto Garcia
2019-01-17 15:33 ` [Qemu-devel] [PATCH 06/13] block: Handle child references in bdrv_reopen_queue() Alberto Garcia
2019-02-12 16:28 ` Kevin Wolf
2019-02-12 16:55 ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2019-02-19 16:00 ` [Qemu-devel] " Alberto Garcia
2019-01-17 15:33 ` [Qemu-devel] [PATCH 07/13] block: Allow omitting the 'backing' option in certain cases Alberto Garcia
2019-02-12 16:38 ` Kevin Wolf
2019-01-17 15:33 ` [Qemu-devel] [PATCH 08/13] block: Allow changing the backing file on reopen Alberto Garcia
2019-02-12 17:27 ` Kevin Wolf
2019-02-21 14:46 ` Alberto Garcia
2019-02-21 14:53 ` Alberto Garcia
2019-01-17 15:34 ` [Qemu-devel] [PATCH 09/13] block: Add 'runtime_opts' and 'mutable_opts' fields to BlockDriver Alberto Garcia
2019-02-12 18:02 ` Kevin Wolf
2019-03-01 12:12 ` Alberto Garcia
2019-03-01 12:36 ` Kevin Wolf
2019-03-01 12:42 ` Alberto Garcia
2019-03-01 12:56 ` Kevin Wolf
2019-03-01 13:05 ` Alberto Garcia
2019-03-01 14:18 ` Kevin Wolf [this message]
2019-03-01 14:37 ` Alberto Garcia
2019-01-17 15:34 ` [Qemu-devel] [PATCH 10/13] block: Add bdrv_reset_options_allowed() Alberto Garcia
2019-01-17 15:34 ` [Qemu-devel] [PATCH 11/13] block: Remove the AioContext parameter from bdrv_reopen_multiple() Alberto Garcia
2019-01-17 15:34 ` [Qemu-devel] [PATCH 12/13] block: Add an 'x-blockdev-reopen' QMP command Alberto Garcia
2019-01-17 15:34 ` [Qemu-devel] [PATCH 13/13] qemu-iotests: Test the x-blockdev-reopen " Alberto Garcia
2019-01-17 15:50 ` [Qemu-devel] [PATCH 00/13] Add a 'x-blockdev-reopen' " Eric Blake
2019-01-17 16:05 ` Alberto Garcia
2019-01-22 8:15 ` Vladimir Sementsov-Ogievskiy
2019-01-23 15:56 ` Alberto Garcia
2019-01-31 15:11 ` Alberto Garcia
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=20190301141809.GD5861@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=berto@igalia.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).