qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Ma Haocong <mahaocong_work@163.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v1 1/1] qemu-img: add new function to remove bitmap in image
Date: Tue, 11 Sep 2018 08:56:19 -0500	[thread overview]
Message-ID: <3a26f63a-f05b-186f-316c-9a91be752065@redhat.com> (raw)
In-Reply-To: <20180911083706.5378-2-mahaocong_work@163.com>

On 9/11/18 3:37 AM, Ma Haocong wrote:
> Signed-off-by: Ma Haocong <mahaocong_work@163.com>
> ---
>   qemu-img-cmds.hx |   6 +++
>   qemu-img.c       | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 125 insertions(+)
> 
> diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
> index 1526f327a5..cc397b64e4 100644
> --- a/qemu-img-cmds.hx
> +++ b/qemu-img-cmds.hx
> @@ -97,6 +97,12 @@ STEXI
>   @item resize [--object @var{objectdef}] [--image-opts] [-f @var{fmt}] [--preallocation=@var{prealloc}] [-q] [--shrink] @var{filename} [+ | -]@var{size}
>   ETEXI
>   
> +DEF("removebmp", img_removebmp,

Not alphabetical - if we keep this name (which I'm already questioning), 
this should come prior to 'resize'.

> +    "removebmp [--object objectdef] [--image-opts] [-q] [-f fmt] filename dirtybitmap")
> +STEXI
> +@item removebmp [--object @var{objectdef}] [--image-opts] [-q] [-f @var{fmt}] @var{filename} @var{dirtybitmap}
> +ETEXI
> +
>   STEXI
>   @end table
>   ETEXI
> diff --git a/qemu-img.c b/qemu-img.c
> index b12f4cd19b..fdafb4a131 100644
> --- a/qemu-img.c
> +++ b/qemu-img.c
> @@ -835,6 +835,125 @@ fail:
>       return ret;
>   }
>   
> +/*
> + * Remove a named dirty bitmap in image.
> + * This command should be used with no other QEMU process
> + * open the image at the same time. Otherwise it may be
> + * croputed the bitmap even the image.

s/be croputed/corrupt/
s/even/or even/

However, the last sentence is not adding anything useful - we already 
have image locking that should make it impossible to attempt to remove a 
bitmap while some other qemu process has the image open.

> + */
> +static int img_removebmp(int argc, char **argv)
> +{
> +    int               c, ret;
> +    const char       *filename, *fmt, *bitmapname;
> +    bool              quiet = false;
> +    BlockBackend     *blk;
> +    BlockDriverState *bs;
> +    BdrvDirtyBitmap  *bitmap;
> +    Error            *local_err = NULL;
> +    bool image_opts = false;
> +    fmt = NULL;
> +
> +    for (;;) {
> +        int option_index = 0;
> +        static const struct option long_options[] = {
> +            {"help", no_argument, 0, 'h'},
> +            {"format", required_argument, 0, 'f'},
> +            {"object", required_argument, 0, OPTION_OBJECT},
> +            {"image-opts", no_argument, 0, OPTION_IMAGE_OPTS},
> +            {0, 0, 0, 0}
> +        };
> +        c = getopt_long(argc, argv, ":hf:q",
> +                        long_options, &option_index);

> +    bitmap = bdrv_find_dirty_bitmap(bs, bitmapname);
> +
> +    /*
> +     * Dirty bitmap may not be load if the 'IN_USE' flag is set (e.g. the
> +     * qemu thread is corrupted and the 'IN_USE' flag is not be cleared),
> +     * so the result of bdrv_find_dirty_bitmap is null. In this case,
> +     * we delete bitmap in qcow2 file directly.
> +    */
> +    if (!bitmap) {
> +        bdrv_remove_persistent_dirty_bitmap(bs, bitmapname, &local_err);
> +        if (local_err != NULL) {
> +            ret = -1;
> +            goto out;
> +        }
> +    } else {
> +        if (bdrv_dirty_bitmap_get_persistance(bitmap)) {
> +            bdrv_remove_persistent_dirty_bitmap(bs, bitmapname, &local_err);
> +            if (local_err != NULL) {
> +                ret = -1;
> +                goto out;
> +            }
> +        }
> +        bdrv_release_dirty_bitmap(bs, bitmap);
> +    }

Why aren't you calling bdrv_block_dirty_bitmap_remove()?  In general, 
HMP commands that are mere wrappers around counterpart QMP commands are 
easier to maintain, rather than open-coding the same work in two places.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

  reply	other threads:[~2018-09-11 14:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-11  8:37 [Qemu-devel] [PATCH v1 0/1] qemu-img: add new function to remove bitmap in image Ma Haocong
2018-09-11  8:37 ` [Qemu-devel] [PATCH v1 1/1] " Ma Haocong
2018-09-11 13:56   ` Eric Blake [this message]
2018-09-11 14:08     ` Eric Blake
2018-09-11 13:49 ` [Qemu-devel] [PATCH v1 0/1] " Eric Blake

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=3a26f63a-f05b-186f-316c-9a91be752065@redhat.com \
    --to=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mahaocong_work@163.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).