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
>
>
> .
>
next prev 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 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).