All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Jeff Cody <jcody@redhat.com>
Cc: kwolf@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org,
	lcapitulino@redhat.com, pbonzini@redhat.com, eblake@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 1/2] qapi: Introduce blockdev-group-snapshot-sync command
Date: Mon, 27 Feb 2012 11:13:29 +0000	[thread overview]
Message-ID: <CAJSP0QV7_1X5674FgNTnvMPTP+y=AT-w=Z4pG1mX8ZC9Hs5A+Q@mail.gmail.com> (raw)
In-Reply-To: <d2f1bf32bf70f2a2651eb40a5f73c8d0f7f9a337.1330282361.git.jcody@redhat.com>

On Sun, Feb 26, 2012 at 7:31 PM, Jeff Cody <jcody@redhat.com> wrote:

Do you have automated tests for this feature?

> +/*
> + * Add new bs contents at the top of an image chain while the chain is live,
> + * while keeping required fields on the top layer.

Please also document the swap behavior.  It's pretty important for the
caller to realize that once this function returns, their
BlockDriverState arguments with have swapped.

> + * It is assumed that bs_new already points to an existing image,
> + * with the correct backing filename of top->backing_file

Not sure what this means.  Isn't bs_new going to use bs_top as its
backing file?  Why "top->backing_file"?

> +void bdrv_append(BlockDriverState *bs_new, BlockDriverState *bs_top)
> +{
> +    BlockDriverState tmp;
> +
> +    /* the new bs must not be in bdrv_states */
> +    bdrv_make_anon(bs_new);
> +
> +    tmp = *bs_new;
> +    tmp.backing_hd = bs_new;

This is tricky, would be nice to comment that we will swap bs_new and
bs_top later, therefore we need a pointer to bs_new here even though
it doesn't make sense yet.

> +
> +    /* there are some fields that need to stay on the top layer: */
> +
> +    /* dev info */
> +    tmp.dev_ops          = bs_top->dev_ops;
> +    tmp.dev_opaque       = bs_top->dev_opaque;
> +    tmp.dev              = bs_top->dev;
> +    tmp.buffer_alignment = bs_top->buffer_alignment;
> +    tmp.copy_on_read     = bs_top->copy_on_read;
> +
> +    /* i/o timing parameters */
> +    tmp.slice_time        = bs_top->slice_time;
> +    tmp.slice_start       = bs_top->slice_start;
> +    tmp.slice_end         = bs_top->slice_end;
> +    tmp.io_limits         = bs_top->io_limits;
> +    tmp.io_base           = bs_top->io_base;
> +    tmp.throttled_reqs    = bs_top->throttled_reqs;
> +    tmp.block_timer       = bs_top->block_timer;
> +    tmp.io_limits_enabled = bs_top->io_limits_enabled;

Please add a comment into BlockDriverState to warn that changes to
fields may require updates to this function too!

> +        /* We will manually add the backing_hd field to the bs later */
> +        states->new_bs = bdrv_new("");
> +        ret = bdrv_open(states->new_bs, snapshot_file,
> +                        flags | BDRV_O_NO_BACKING, drv);
> +        states->is_open = true;

What is the point of is_open?  If we failed then new_bs is actually
not open here.

I think you can remove this field and just do the following in close_and_fail:

if (states->new_bs) {
    bdrv_delete(states->new_bs);
}

(BTW I think close_and_fail is currently leaking new_bs because it
only closes it and does not delete it!)

  reply	other threads:[~2012-02-27 11:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-26 19:31 [Qemu-devel] [PATCH v2 0/2] Group Live Snapshots Jeff Cody
2012-02-26 19:31 ` [Qemu-devel] [PATCH v2 1/2] qapi: Introduce blockdev-group-snapshot-sync command Jeff Cody
2012-02-27 11:13   ` Stefan Hajnoczi [this message]
2012-02-27 14:26     ` Jeff Cody
2012-02-27 14:40       ` Stefan Hajnoczi
2012-02-27 15:23         ` Jeff Cody
2012-02-27 15:31           ` Stefan Hajnoczi
2012-02-27 15:46   ` Kevin Wolf
2012-02-27 16:51     ` Paolo Bonzini
2012-02-27 17:02     ` Jeff Cody
2012-02-27 17:22       ` Kevin Wolf
2012-02-27 17:31         ` Jeff Cody
2012-02-26 19:31 ` [Qemu-devel] [PATCH v2 2/2] QMP: Add qmp command for blockdev-group-snapshot-sync Jeff Cody

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='CAJSP0QV7_1X5674FgNTnvMPTP+y=AT-w=Z4pG1mX8ZC9Hs5A+Q@mail.gmail.com' \
    --to=stefanha@gmail.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=pbonzini@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.