Re: [Qemu-block] [RFC PATCH 05/10] block: Add 'keep_old_opts' parameter to bdrv_reopen_queue()
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
Re: [Qemu-block] [RFC PATCH 05/10] block: Add 'keep_old_opts' parameter to bdrv_reopen_queue()
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. Berto
Re: [Qemu-block] [RFC PATCH 05/10] block: Add 'keep_old_opts' parameter to bdrv_reopen_queue()
Am 14.06.2018 um 17:49 hat Alberto Garcia geschrieben: > The bdrv_reopen_queue() function is used to create a queue with the > BDSs that are going to be reopened and their new options. Once the > queue is ready bdrv_reopen_multiple() is called to perform the > operation. > > The original options from each one of the BDSs are kept, with the new > options passed to bdrv_reopen_queue() applied on top of them. > > For "x-blockdev-reopen" we want a function that behaves much like > "blockdev-add". We want to ignore the previous set of options so that > only the ones actually specified by the user are applied, with the > rest having their default values. > > We can achieve this by adding a new parameter to bdrv_reopen_queue() > that specifies whether the old set of options is kept or discarded > when building the reopen queue. All current callers will set that > parameter to true, but x-blockdev-reopen will set it to false. > > Signed-off-by: Alberto Garcia > --- > block.c | 34 +++--- > block/replication.c | 4 ++-- > include/block/block.h | 3 ++- > qemu-io-cmds.c| 2 +- > 4 files changed, 24 insertions(+), 19 deletions(-) > > diff --git a/block.c b/block.c > index a741300fae..0b9268a48d 100644 > --- a/block.c > +++ b/block.c > @@ -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. Kevin