Re: [Qemu-block] [RFC PATCH 05/10] block: Add 'keep_old_opts' parameter to bdrv_reopen_queue()

2018-06-18 Thread Kevin Wolf
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()

2018-06-18 Thread Alberto Garcia
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()

2018-06-18 Thread Kevin Wolf
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