From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:39047)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <berto@igalia.com>) id 1Zbm2m-0000Xi-5o
	for qemu-devel@nongnu.org; Tue, 15 Sep 2015 04:56:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <berto@igalia.com>) id 1Zbm2i-0002Ij-0Q
	for qemu-devel@nongnu.org; Tue, 15 Sep 2015 04:56:52 -0400
From: Alberto Garcia <berto@igalia.com>
In-Reply-To: <20150914153700.GE3550@noname.str.redhat.com>
References: <1441878905-5272-1-git-send-email-wency@cn.fujitsu.com>
	<1441878905-5272-5-git-send-email-wency@cn.fujitsu.com>
	<20150914153700.GE3550@noname.str.redhat.com>
Date: Tue, 15 Sep 2015 10:56:44 +0200
Message-ID: <w51y4g8awmr.fsf@maestria.local.igalia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [Qemu-devel] [PATCH v3 4/5] qmp: add monitor command to
	add/remove a child
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>, Wen Congyang <wency@cn.fujitsu.com>
Cc: zhanghailiang <zhang.zhanghailiang@huawei.com>, qemu block <qemu-block@nongnu.org>, Markus Armbruster <armbru@redhat.com>, Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>, "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu devel <qemu-devel@nongnu.org>, Gonglei <arei.gonglei@huawei.com>, Stefan Hajnoczi <stefanha@redhat.com>, Yang Hongyang <yanghy@cn.fujitsu.com>

On Mon 14 Sep 2015 05:37:00 PM CEST, Kevin Wolf <kwolf@redhat.com> wrote:

>> +{ 'command': 'x-child-add',
>> +  'data' : { 'parent': 'str', 'child': 'str' } }
>
> This is probably not future-proof and only made for the special case
> of quorum. Specifically, one thing I'm missing is some way to specfiy
> what kind of child the new node is when a node can take different
> types of children (e.g. bs->file and bs->backing_hd).

Children here are specified by child roles, aren't they?

We could have a ChildRole enum with 'file', 'format' and 'backing' that
would be passed to this command and use the same enumeration in
bdrv_open_image() rather than a pointer to BdrvChildRole.

Berto