qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v19 04/16] block: Replace in_use with operation


From: Fam Zheng
Subject: Re: [Qemu-devel] [PATCH v19 04/16] block: Replace in_use with operation blocker
Date: Tue, 20 May 2014 11:26:40 +0800
User-agent: Mutt/1.5.23 (2014-03-12)

On Mon, 05/19 16:28, Markus Armbruster wrote:
> Fam Zheng <address@hidden> writes:
> 
> > This drops BlockDriverState.in_use with op_blockers:
> >
> >   - Call bdrv_op_block_all in place of bdrv_set_in_use(bs, 1).
> >   - Call bdrv_op_unblock_all in place of bdrv_set_in_use(bs, 0).
> >   - Check bdrv_op_is_blocked() in place of bdrv_in_use(bs).
> >     The specific types are used, e.g. in place of starting block backup,
> >     bdrv_op_is_blocked(bs, BLOCK_OP_TYPE_BACKUP, ...).
> >   - Check bdrv_op_blocker_is_empty() in place of assert(!bs->in_use).
> >
> > Note: there is only bdrv_op_block_all and bdrv_op_unblock_all callers at
> > this moment. So although the checks are specific to op types, this
> > changes can still be seen as identical logic with previously with
> > in_use. The difference is error message are improved because of blocker
> > error info.
> >
> > Signed-off-by: Fam Zheng <address@hidden>
> > Reviewed-by: Jeff Cody <address@hidden>
> > ---
> >  block-migration.c               |  7 +++++--
> >  block.c                         | 24 +++++++-----------------
> >  blockdev.c                      | 19 +++++++++----------
> >  blockjob.c                      | 14 +++++++++-----
> >  hw/block/dataplane/virtio-blk.c | 18 ++++++++++++------
> >  include/block/block.h           |  2 --
> >  include/block/block_int.h       |  1 -
> >  include/block/blockjob.h        |  3 +++
> >  8 files changed, 45 insertions(+), 43 deletions(-)
> >
> > diff --git a/block-migration.c b/block-migration.c
> > index 56951e0..1656270 100644
> > --- a/block-migration.c
> > +++ b/block-migration.c
> > @@ -59,6 +59,7 @@ typedef struct BlkMigDevState {
> >      unsigned long *aio_bitmap;
> >      int64_t completed_sectors;
> >      BdrvDirtyBitmap *dirty_bitmap;
> > +    Error *blocker;
> >  } BlkMigDevState;
> >  
> >  typedef struct BlkMigBlock {
> > @@ -361,7 +362,8 @@ static void init_blk_migration_it(void *opaque, 
> > BlockDriverState *bs)
> >          bmds->completed_sectors = 0;
> >          bmds->shared_base = block_mig_state.shared_base;
> >          alloc_aio_bitmap(bmds);
> > -        bdrv_set_in_use(bs, 1);
> > +        error_setg(&bmds->blocker, "block device is in use by migration");
> > +        bdrv_op_block_all(bs, bmds->blocker);
> >          bdrv_ref(bs);
> >  
> >          block_mig_state.total_sector_sum += sectors;
> 
> Unlike QERR_DEVICE_IN_USE, this message doesn't include the device name.
> Did you verify it's not needed to make sense of the message?

I prefer not adding device name in the ->block error message, because we can
always get the device name from the bs pointer. In other words this should be
handled in bdrv_op_is_blocked() generally, will update patch 03/16.

<...>

> > diff --git a/blockjob.c b/blockjob.c
> > index cd4784f..60e72f5 100644
> > --- a/blockjob.c
> > +++ b/blockjob.c
> > @@ -41,14 +41,16 @@ void *block_job_create(const BlockJobDriver *driver, 
> > BlockDriverState *bs,
> >  {
> >      BlockJob *job;
> >  
> > -    if (bs->job || bdrv_in_use(bs)) {
> > +    if (bs->job || !bdrv_op_blocker_is_empty(bs)) {
> >          error_set(errp, QERR_DEVICE_IN_USE, bdrv_get_device_name(bs));
> >          return NULL;
> >      }
> 
> Elsewhere, you replace bdrv_in_use() by bdrv_op_is_blocked().  Why not
> here?

There is no suitable BLOCK_OP_TYPE_ for this because we don't know what caller
does with the created job.

Maybe add a BLOCK_OP_TYPE_ANY special type makes it clearer, but it's logically
identical to !bdrv_op_blocker_is_empty().

That said, a BLOCK_OP_TYPE_ANY is AFAICT only useful here, and even this one
will be dropped in patch 05/16.

> 
> Doesn't this contradict the commit message?

So I'd prefer to update the commit message.

Fam



reply via email to

[Prev in Thread] Current Thread [Next in Thread]