[2/3] block: tell drivers about an image resize

Add a new size_changed flag in the BlockDriverState and call the
change_cb callback to notify drivers about a size change.

Signed-off-by: Christoph Hellwig <hch@lst.de>

* Christoph Hellwig <hch@lst.de> [2011-01-14 10:27]:
> Add a new size_changed flag in the BlockDriverState and call the
> change_cb callback to notify drivers about a size change.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Index: qemu/block.c
> ===================================================================
> --- qemu.orig/block.c	2011-01-14 17:05:49.527003363 +0100
> +++ qemu/block.c	2011-01-14 17:07:23.206255143 +0100
> @@ -1135,6 +1135,10 @@ int bdrv_truncate(BlockDriverState *bs,
>      ret = drv->bdrv_truncate(bs, offset);
>      if (ret == 0) {
>          ret = refresh_total_sectors(bs, offset >> BDRV_SECTOR_BITS);
> +        if (bs->change_cb) {
> +            bs->size_changed = 1;
> +            bs->change_cb(bs->change_opaque);
> +        }

Do we want to check to ensure the size_changed flag isn't set before
doing a second resize event?  I'm wondering if the truncate takes
$longtime and user gets impatient and issues a second resize command.
How should we respond?  Ignore it?  queue it up? 

Is there any other path that invokes bdrv_truncate?  If so, do we want
invoke the call back in those scenarios or only if the truncate is
initiated from the monitor invocation?

>      }
>      return ret;
>  }
> Index: qemu/block_int.h
> ===================================================================
> --- qemu.orig/block_int.h	2011-01-14 17:05:49.537004411 +0100
> +++ qemu/block_int.h	2011-01-14 17:06:02.539004271 +0100
> @@ -167,6 +167,7 @@ struct BlockDriverState {
>      char backing_format[16]; /* if non-zero and backing_file exists */
>      int is_temporary;
>      int media_changed;
> +    int size_changed;
> 
>      BlockDriverState *backing_hd;
>      BlockDriverState *file;

> Do we want to check to ensure the size_changed flag isn't set before
> doing a second resize event?  I'm wondering if the truncate takes
> $longtime and user gets impatient and issues a second resize command.
> How should we respond?  Ignore it?  queue it up? 

The truncate is synchronous and the monitor command won't return before
it's done.  The interfact might be a bit cleaner if we'd just pass the
reason for the change callback as another argument.  I'll do that for
the next respin.

> Is there any other path that invokes bdrv_truncate?  If so, do we want
> invoke the call back in those scenarios or only if the truncate is
> initiated from the monitor invocation?

Currently only the qemu-img and qemu-io tools invooke bdrv_truncate.
But if we grow new users we should always tell the driver/guest about it
so that it knows about the size change.