All of lore.kernel.org
 help / color / mirror / Atom feed
From: Changlong Xie <xiecl.fnst@cn.fujitsu.com>
To: Alberto Garcia <berto@igalia.com>,
	qemu devel <qemu-devel@nongnu.org>,
	Eric Blake <eblake@redhat.com>, Kevin Wolf <kwolf@redhat.com>,
	Max Reitz <mreitz@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Dong Eddie <eddie.dong@intel.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Wen Congyang <wency@cn.fujitsu.com>,
	qemu block <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v13 2/3] quorum: implement bdrv_add_child() and bdrv_del_child()
Date: Tue, 10 May 2016 14:59:55 +0800	[thread overview]
Message-ID: <573186EB.1090008@cn.fujitsu.com> (raw)
In-Reply-To: <w514ma76xfy.fsf@maestria.local.igalia.com>

On 05/09/2016 11:52 PM, Alberto Garcia wrote:
> On Wed 13 Apr 2016 10:33:08 AM CEST, Changlong Xie wrote:
>
> Sorry for the late reply!
>

Never mind : )

> The patch looks good, I have some additional comments on top of what Max
> Wrote, nothing serious though :)
>
>> @@ -67,6 +68,9 @@ typedef struct QuorumVotes {
>>   typedef struct BDRVQuorumState {
>>       BdrvChild **children;  /* children BlockDriverStates */
>>       int num_children;      /* children count */
>> +    uint64_t last_index;   /* indicate the child role name of the last
>> +                            * element of children array
>> +                            */
>
> I think you can use a regular 'unsigned' here, it's simpler and more
> efficient. We're not going to have 2^32 Quorum children, are we? :)
>

Actually, i tried to use 'unsinged' here in my first version. But 
thinking of if someone did crazy child add/delete test(add 10 children 
per second), it will overflow in about 2^32/(60*60*24*365*10) = 13 
years, so i choiced uint64_t(2^64 is big enough) here.
Now, i argree with you, it's overwrought. Will use 'unsigned' in next 
version.

>> +static void quorum_add_child(BlockDriverState *bs, BlockDriverState *child_bs,
>> +                             Error **errp)
>> +{
>> +    BDRVQuorumState *s = bs->opaque;
>> +    BdrvChild *child;
>> +    char indexstr[32];
>> +    int ret;
>> +
>> +    assert(s->num_children <= INT_MAX / sizeof(BdrvChild *) &&
>> +           s->last_index <= UINT64_MAX);
>
> That last condition has no practical effect. last_index is a uint64_t so
> s->last_index <= UINT64_MAX is always going to be true.

Yes, it's redundant code.

>
>> +    s->children = g_renew(BdrvChild *, s->children, s->num_children + 1);
>> +    s->children[s->num_children++] = child;
>
> Slightly simpler way:
>
>         s->children = g_renew(BdrvChild *, s->children, ++s->num_children);
>         s->children[s->num_children] = child;

Overflow arrays, should (s->num_children - 1) here. I'll keep my 
original one.

>
> But this is not very important, so you can leave it as it is now if you
> prefer.
>
>> +    /* child->name is "children.%d" */
>> +    assert(!strncmp(child->name, "children.", 9));
>
> I actually don't think there's anything wrong with this assertion, but
> if you decide to keep it you can use g_str_has_prefix() instead, which
> is a bit easier and more readable.
>

Just as Max said, it's extra check, and will remove it.

>> +    /* We can safely remove this child now */
>> +    memmove(&s->children[i], &s->children[i + 1],
>> +            (s->num_children - i - 1) * sizeof(BdrvChild *));
>> +    s->children = g_renew(BdrvChild *, s->children, --s->num_children);
>> +    bdrv_unref_child(bs, child);
>
> Question: do we want to decrement last_index if 'i' is the last
> children? Something like:
>

I agree with Max, it seems no benifit(although will save number 
resources if (i == s->num_children - 1)) here.

Thanks
	-Xie

> if (i == s->num_children - 1) {
>     s->last_index--;
> } else {
>     memmove(...)
> }
> s->children = g_renew(...)
>
> Berto
>
>
> .
>

  parent reply	other threads:[~2016-05-10  6:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13  8:33 [Qemu-devel] [PATCH v13 0/3] qapi: child add/delete support Changlong Xie
2016-04-13  8:33 ` [Qemu-devel] [PATCH v13 1/3] Add new block driver interface to add/delete a BDS's child Changlong Xie
2016-04-13  8:33 ` [Qemu-devel] [PATCH v13 2/3] quorum: implement bdrv_add_child() and bdrv_del_child() Changlong Xie
2016-04-20  3:36   ` Changlong Xie
2016-05-06 15:20   ` Max Reitz
2016-05-09  9:26     ` Changlong Xie
2016-05-09 15:52   ` Alberto Garcia
2016-05-09 16:50     ` Max Reitz
2016-05-10  6:59     ` Changlong Xie [this message]
2016-05-10  8:39     ` Kevin Wolf
2016-05-10  8:45       ` Alberto Garcia
2016-04-13  8:33 ` [Qemu-devel] [PATCH v13 3/3] qmp: add monitor command to add/remove a child Changlong Xie

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=573186EB.1090008@cn.fujitsu.com \
    --to=xiecl.fnst@cn.fujitsu.com \
    --cc=armbru@redhat.com \
    --cc=berto@igalia.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eddie.dong@intel.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=wency@cn.fujitsu.com \
    --cc=yunhong.jiang@intel.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.