All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: "Benoît Canet" <benoit.canet@irqsave.net>,
	"Anthony Liguori" <aliguori@us.ibm.com>,
	benoit.canet@gmail.com, stefanha@linux.vnet.ibm.com,
	stefanha@gmail.com, qemu-devel@nongnu.org, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy()
Date: Tue, 24 Jul 2012 15:29:11 +0200	[thread overview]
Message-ID: <500EA327.7040107@redhat.com> (raw)
In-Reply-To: <20120724095548.2bf348d8@doriath.home>

Am 24.07.2012 14:55, schrieb Luiz Capitulino:
> On Tue, 24 Jul 2012 12:10:39 +0200
> Benoît Canet <benoit.canet@irqsave.net> wrote:
> 
>> Le Monday 23 Jul 2012 à 14:15:01 (-0300), Luiz Capitulino a écrit :
>>> On Mon, 23 Jul 2012 16:22:58 +0200
>>> benoit.canet@gmail.com wrote:
>>>
>>>> From: Benoît Canet <benoit@irqsave.net>
>>>>
>>>> bdrv_are_busy will be used to check if any of the bs are in use
>>>> or if one of them have a running block job.
>>>>
>>>> The first user will be qmp_migrate().
>>>>
>>>> Signed-off-by: Benoit Canet <benoit@irqsave.net>
>>>> ---
>>>>  block.c |   13 +++++++++++++
>>>>  block.h |    2 ++
>>>>  2 files changed, 15 insertions(+)
>>>>
>>>> diff --git a/block.c b/block.c
>>>> index ce7eb8f..bc8f160 100644
>>>> --- a/block.c
>>>> +++ b/block.c
>>>> @@ -4027,6 +4027,19 @@ out:
>>>>      return ret;
>>>>  }
>>>>  
>>>> +int bdrv_are_busy(void)
>>>> +{
>>>> +    BlockDriverState *bs;
>>>> +
>>>> +    QTAILQ_FOREACH(bs, &bdrv_states, list) {
>>>> +        if (bs->job || bdrv_in_use(bs)) {
>>>> +            return -EBUSY;
>>>> +        }
>>>> +    }
>>>
>>> IMO, this should return true/false. The name is a bit misleading too, as it
>>> gives the impression that are existing bdrvs are busy. I'd call it
>>> bdrv_any_busy() or bdrv_any_in_use().
>>
>> Hello Anthony,
>>
>> Stefanha is in favor of returning -EBUSY and Luiz Capitulino would prefer
>> the function to return a boolean.
>> Could you decide which option is the best ?
> 
> Stefan's opnion certainly has precedence over mine on block layer stuff,
> this was just an IMO.
> 
> Stefan, did you consider returning a boolean?

I'm with you in this point, Luiz (as well as with the rename to
bdrv_is_any_busy). And actually I think Benoît may have misunderstood
and Stefan is as well. What he said is:

> I think bdrv_have_block_jobs() is too specific and would use
> bdrv_in_use(bs) here to give basically an EBUSY-type error.

I don't think this was about bool vs. -errno, but more about checking
only block jobs vs. all kinds of things that can have a block device in use.

Anyway, I believe we came to the conclusion that even the intention of
the series is wrong, as in many cases migrating while an image is being
streamed is perfectly fine. So the details don't really matter any more.

Kevin

  reply	other threads:[~2012-07-24 13:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-23 14:22 [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy benoit.canet
2012-07-23 14:22 ` [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy() benoit.canet
2012-07-23 17:15   ` Luiz Capitulino
2012-07-24 10:10     ` Benoît Canet
2012-07-24 12:55       ` Luiz Capitulino
2012-07-24 13:29         ` Kevin Wolf [this message]
2012-07-24 14:37           ` Benoît Canet
2012-07-24 14:42             ` Kevin Wolf
2012-07-23 14:22 ` [Qemu-devel] [PATCH V4 2/3] qerror: Add error telling that block dev usage prevents migration benoit.canet
2012-07-23 17:09   ` Luiz Capitulino
2012-07-23 14:23 ` [Qemu-devel] [PATCH V4 3/3] migration: block migration when any of the block device is busy benoit.canet
2012-07-23 14:58 ` [Qemu-devel] [PATCH V4 0/3] Block migration if " Stefan Hajnoczi
2012-07-24  9:52 ` Kevin Wolf
2012-07-24 10:04   ` Stefan Hajnoczi
2012-07-24 10:19     ` Kevin Wolf
2012-07-24 11:12       ` Paolo Bonzini

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=500EA327.7040107@redhat.com \
    --to=kwolf@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=benoit.canet@gmail.com \
    --cc=benoit.canet@irqsave.net \
    --cc=lcapitulino@redhat.com \
    --cc=pbonzini@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 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.