All of lore.kernel.org
 help / color / mirror / Atom feed
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>, Eric Blake <eblake@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH 05/10] block: Add 'keep_old_opts' parameter to bdrv_reopen_queue()
Date: Mon, 18 Jun 2018 18:15:46 +0200	[thread overview]
Message-ID: <20180618161546.GE4667@localhost.localdomain> (raw)
In-Reply-To: <w51fu1kp10f.fsf@maestria.local.igalia.com>

Am 18.06.2018 um 17:28 hat Alberto Garcia geschrieben:
> On Mon 18 Jun 2018 04:15:07 PM CEST, Kevin Wolf wrote:
> 
> >> @@ -2850,7 +2850,8 @@ static BlockReopenQueue *bdrv_reopen_queue_child(BlockReopenQueue *bs_queue,
> >>                                                   int flags,
> >>                                                   const BdrvChildRole *role,
> >>                                                   QDict *parent_options,
> >> -                                                 int parent_flags)
> >> +                                                 int parent_flags,
> >> +                                                 bool keep_old_opts)
> >
> > Can we change the semantics of keep_old_opts so that flags is completely
> > ignored for keep_old_opts=false?
> >
> > Flags are one of the reasons why the behaviour of bdrv_reopen() is
> > rather complex and I'd prefer not having that complexity in a public
> > interface. To be honest, I wouldn't be sure that I could write a
> > correct documentation with it.
> 
> I think so. In this series if keep_old_opts is false the only possible
> flags are either 0 or BDRV_O_RDWR | BDRV_O_ALLOW_RDWR, depending on the
> value of "read-only" option.

I assume the default options that you have to set in
qmp_x_blockdev_reopen() are only because update_options_from_flags()
would break things otherwise. So if we get rid of the latter, maybe we
can simplify qmp_x_blockdev_reopen(), too.

Well, or maybe my assumption is just wrong, of course.

KEvin

  reply	other threads:[~2018-06-18 16:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-14 15:48 [Qemu-devel] [RFC PATCH 00/10] Add a 'x-blockdev-reopen' QMP command Alberto Garcia
2018-06-14 15:48 ` [Qemu-devel] [RFC PATCH 01/10] file-posix: Forbid trying to change unsupported options during reopen Alberto Garcia
2018-06-14 15:48 ` [Qemu-devel] [RFC PATCH 02/10] block: Allow changing 'discard' on reopen Alberto Garcia
2018-06-14 15:49 ` [Qemu-devel] [RFC PATCH 03/10] block: Allow changing 'detect-zeroes' " Alberto Garcia
2018-06-14 15:49 ` [Qemu-devel] [RFC PATCH 04/10] block: Allow changing 'force-share' " Alberto Garcia
2018-06-14 15:49 ` [Qemu-devel] [RFC PATCH 05/10] block: Add 'keep_old_opts' parameter to bdrv_reopen_queue() Alberto Garcia
2018-06-18 14:15   ` Kevin Wolf
2018-06-18 15:28     ` Alberto Garcia
2018-06-18 16:15       ` Kevin Wolf [this message]
2018-06-14 15:49 ` [Qemu-devel] [RFC PATCH 06/10] block: Allow changing the backing file on reopen Alberto Garcia
2018-06-18 14:38   ` Kevin Wolf
2018-06-18 15:06     ` Alberto Garcia
2018-06-18 16:12       ` Kevin Wolf
2018-06-19 12:27         ` Alberto Garcia
2018-06-19 13:05           ` Kevin Wolf
2018-06-19 14:20             ` Alberto Garcia
2018-06-20 10:58               ` Kevin Wolf
2018-06-20 12:35                 ` Alberto Garcia
2018-06-21 13:06                   ` Kevin Wolf
2018-09-12 15:09                     ` Alberto Garcia
2018-06-14 15:49 ` [Qemu-devel] [RFC PATCH 07/10] block: Add 'runtime_opts' and 'mutable_opts' fields to BlockDriver Alberto Garcia
2018-06-14 15:49 ` [Qemu-devel] [RFC PATCH 08/10] block: Add bdrv_reset_options_allowed() Alberto Garcia
2018-06-14 15:49 ` [Qemu-devel] [RFC PATCH 09/10] block: Add a 'x-blockdev-reopen' QMP command Alberto Garcia
2018-06-14 15:49 ` [Qemu-devel] [RFC PATCH 10/10] qemu-iotests: Test the x-blockdev-reopen " 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=20180618161546.GE4667@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berto@igalia.com \
    --cc=eblake@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.