All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: famz@redhat.com
Cc: kwolf@redhat.com, obarenbo@redhat.com, armbru@redhat.com,
	roliveri@redhat.com, hbrock@redhat.com, qemu-devel@nongnu.org,
	rjones@redhat.com, pmyers@redhat.com, imain@redhat.com,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-backup QMP command
Date: Thu, 27 Jun 2013 13:40:31 +0200	[thread overview]
Message-ID: <51CC24AF.9010001@redhat.com> (raw)
In-Reply-To: <20130627113722.GA22728@t430s.nay.redhat.com>

Il 27/06/2013 13:37, Fam Zheng ha scritto:
>>> > > 
>>> > > Yes, this makes me realize that ref count it not a solution to retire
>>> > > bs->in_use, because we can't tell if drive-del or block-resize is safe
>>> > > with only reference number. But I can't think of two situations to deny
>>> > > different subsets of commands, shouldn't a general blocker, like in_use
>>> > > does, be good enough?
>> > 
>> > For example, right now nbd-server-add does not check bdrv_in_use.  But
>> > shrinking a device that is exposed via NBD could be surprising to the
>> > NBD clients.
>> > 
> So it seems to me that both block job and nbd server have the same
> restriction on device: don't resize, and notify on close. So my question
> is if we implement bdrv_add_command_blocker(), do the callers still need to distinguish what actions to block, or it's generally to block all the actions those change the device parameter?

It would be a good start to have a list of things that are setting and
checking bdrv_in_use.  Then we can make a matrix.

Paolo

  reply	other threads:[~2013-06-27 11:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-26  3:59 [Qemu-devel] [RFC PATCH 0/3] Point-in-time snapshot exporting with drive-backup Fam Zheng
2013-06-26  3:59 ` [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-backup QMP command Fam Zheng
2013-06-27  8:15   ` Stefan Hajnoczi
2013-06-27  9:41     ` Fam Zheng
2013-06-27 10:57       ` Paolo Bonzini
2013-06-27 11:37         ` Fam Zheng
2013-06-27 11:40           ` Paolo Bonzini [this message]
2013-06-28  2:17             ` Fam Zheng
2013-06-26  3:59 ` [Qemu-devel] [RFC PATCH 2/3] block: assign backing relationship in drive-backup Fam Zheng
2013-06-26  7:15   ` Paolo Bonzini
2013-06-26  3:59 ` [Qemu-devel] [RFC PATCH 3/3] nbd: don't get ref if bs has no drive Fam Zheng
2013-06-26  7:23 ` [Qemu-devel] [RFC PATCH 0/3] Point-in-time snapshot exporting with drive-backup Paolo Bonzini
2013-06-26  7:31   ` Fam Zheng
2013-06-27  8:17     ` Stefan Hajnoczi
2013-06-27 10:06       ` Paolo Bonzini
2013-06-27 13:39         ` Stefan Hajnoczi

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=51CC24AF.9010001@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=armbru@redhat.com \
    --cc=famz@redhat.com \
    --cc=hbrock@redhat.com \
    --cc=imain@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=obarenbo@redhat.com \
    --cc=pmyers@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    --cc=roliveri@redhat.com \
    --cc=stefanha@redhat.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 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.