qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: kwolf@redhat.com, stefanha@linux.vnet.ibm.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [patch 4/5] block stream: add support for partial streaming
Date: Wed, 4 Jan 2012 11:52:07 -0200	[thread overview]
Message-ID: <20120104135206.GA15452@amt.cnet> (raw)
In-Reply-To: <CAJSP0QW+cD1mFZ1+-mqFwU+5qDu=o7gHa2RchuDP1pVoS-QOEw@mail.gmail.com>

On Wed, Jan 04, 2012 at 12:39:57PM +0000, Stefan Hajnoczi wrote:
> On Fri, Dec 30, 2011 at 10:03 AM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
> > +int bdrv_is_allocated_base(BlockDriverState *top,
> > +                           BlockDriverState *base,
> > +                           int64_t sector_num,
> > +                           int nb_sectors, int *pnum)
> 
> Since this function runs in coroutine context it should be marked:
> int coroutine_fn bdrv_co_is_allocated_base(...)
> 
> The _co_ in the filename is just a convention to identify block layer
> functions that execute in coroutine context.  The coroutine_fn
> annotation is useful if we ever want static checker support that
> verifies that coroutine functions are always called from coroutine
> context.

Done.

> > +{
> > +    BlockDriverState *intermediate;
> > +    int ret, n;
> > +
> > +    ret = bdrv_co_is_allocated(top, sector_num, nb_sectors, &n);
> > +    if (ret) {
> > +        *pnum = n;
> > +        return ret;
> > +    }
> > +
> > +    /*
> > +     * Is the unallocated chunk [sector_num, n] also
> > +     * unallocated between base and top?
> > +     */
> > +    intermediate = top->backing_hd;
> 
> This reaches into BlockDriverState->backing_hd.  In practice this is
> probably the simplest and best way to do it.  But if we're going to do
> this then do we even need the BlockDriver .bdrv_find_backing_file()
> abstraction?  We could implement generic code which traverses
> ->backing_hd in block.c and if you don't use
> BlockDriverState->backing_hd then you're out of luck.

Right. Then it becomes necessary for drivers to fill in 
->backing_hd and ->backing_file properly, which is reasonable.

Will drop the abstractions.

> > @@ -129,7 +141,10 @@ retry:
> >     bdrv_disable_zero_detection(bs);
> >
> >     if (sector_num == end && ret == 0) {
> > -        bdrv_change_backing_file(bs, NULL, NULL);
> > +        const char *base_id = NULL;
> > +        if (base)
> > +            base_id = s->backing_file_id;
> > +        bdrv_change_backing_file(bs, base_id, NULL);
> 
> This makes me want to move the bdrv_change_backing_file() call out to
> blockdev.c where we would perform it on successful completion.  That
> way we don't need to pass base_id into stream.c at all.  A streaming
> block job would no longer automatically change the backing file on
> completion.

Well, it is safer to perform the backing file change under refcounting 
protection (i don't see the advantage of your suggestion
other than the cosmetic aspect of saving a variable).

> > @@ -166,6 +182,8 @@ int stream_start(BlockDriverState *bs, B
> >
> >     s = block_job_create(&stream_job_type, bs, cb, opaque);
> >     s->base = base;
> > +    if (base_id)
> > +        strncpy(s->backing_file_id, base_id, sizeof(s->backing_file_id) - 1);
> 
> cutils.c:pstrcpy() is nicer than strncpy(), it does not need the size - 1.

Done.

  reply	other threads:[~2012-01-04 13:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-30 10:03 [Qemu-devel] [patch 0/5] block streaming base support Marcelo Tosatti
2011-12-30 10:03 ` [Qemu-devel] [patch 1/5] block: add bdrv_find_backing_image Marcelo Tosatti
2011-12-30 10:03 ` [Qemu-devel] [patch 2/5] block: implement bdrv_find_backing_image in qcow2 Marcelo Tosatti
2012-01-03 13:44   ` Stefan Hajnoczi
2011-12-30 10:03 ` [Qemu-devel] [patch 3/5] add QERR_BASE_ID_NOT_FOUND Marcelo Tosatti
2011-12-30 10:03 ` [Qemu-devel] [patch 4/5] block stream: add support for partial streaming Marcelo Tosatti
2012-01-04 12:39   ` Stefan Hajnoczi
2012-01-04 13:52     ` Marcelo Tosatti [this message]
2011-12-30 10:03 ` [Qemu-devel] [patch 5/5] add doc to describe live block operations Marcelo Tosatti
2012-01-04 14:08 ` [Qemu-devel] [patch 0/4] block streaming base support (v2) Marcelo Tosatti
2012-01-04 14:08   ` [Qemu-devel] [patch 1/4] block: add bdrv_find_backing_image Marcelo Tosatti
2012-01-04 14:08   ` [Qemu-devel] [patch 2/4] add QERR_BASE_ID_NOT_FOUND Marcelo Tosatti
2012-01-04 14:08   ` [Qemu-devel] [patch 3/4] block stream: add support for partial streaming Marcelo Tosatti
2012-01-04 16:02     ` Eric Blake
2012-01-04 17:47       ` Marcelo Tosatti
2012-01-04 18:03         ` Eric Blake
2012-01-04 19:22           ` Marcelo Tosatti
2012-01-04 22:40           ` Stefan Hajnoczi
2012-01-05  7:46             ` Paolo Bonzini
2012-01-09 10:58             ` Kevin Wolf
2012-01-09 13:14               ` Stefan Hajnoczi
2012-01-04 14:08   ` [Qemu-devel] [patch 4/4] add doc to describe live block operations Marcelo Tosatti

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=20120104135206.GA15452@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@linux.vnet.ibm.com \
    /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).