From: Max Reitz <mreitz@redhat.com>
To: Wen Congyang <wency@cn.fujitsu.com>, qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [RFC for-2.7 1/1] block/qapi: Add query-block-node-tree
Date: Sat, 26 Mar 2016 17:27:11 +0100 [thread overview]
Message-ID: <56F6B85F.2090501@redhat.com> (raw)
In-Reply-To: <56F4A790.4020609@cn.fujitsu.com>
[-- Attachment #1.1: Type: text/plain, Size: 2011 bytes --]
On 25.03.2016 03:50, Wen Congyang wrote:
> On 03/25/2016 03:07 AM, Max Reitz wrote:
>> This command returns the tree of BlockDriverStates under a given root
>> node.
>>
>> Every tree node is described by its node name and the connection of a
>> parent node to its children additionally contains the role the child
>> assumes.
>>
>> A node's name can then be used e.g. in conjunction with
>> query-named-block-nodes to get more information about the node.
>
> I test this patch, and it works.
> {'execute': 'query-block-node-tree', 'arguments': {'root-node': 'disk1' } }
> {"return": {"children": [{"role": "children.0", "node": {"children": [{"role": "file", "node": {"children": [], "node-name": "#block175"}}], "node-name": "#block267"}}], "node-name": "#block040"}}
>
> Shoule we hide the node name like "#blockxxx"?
No, I don't think so. In fact I was thinking of making the node name
non-optional because every BDS should have one due to these
auto-generated ones.
> If the bs doesn't have any child, should we output: '"children": [], '?
Omitting an empty array (thus making the @children key optional)
occurred to me, too. I didn't find any strong reason to do so, however.
It makes generating the output a bit more complicated and may also make
parsing it just a tiny bit more complicated.
I think that omitting it would make more sense to a human reader, but
QMP is a machine protocol, so this is not a very strong argument.
So all in all I saw neither strong arguments to omit an empty array nor
to include it. Thus I included it because that makes the code simpler.
> Can we add a new parameter: depth? For example, If I only want to know the quorum's
> child name, we can limit the depth, and the output may be very clear.
Good idea. I can do so in the next version, but first I'd like to hear
more opinions on what other people think of this command. If they think
it's fine, I'll include a depth parameter.
Thank you for you comments!
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-03-26 16:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-24 19:07 [Qemu-devel] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree Max Reitz
2016-03-24 19:07 ` [Qemu-devel] [RFC for-2.7 1/1] " Max Reitz
2016-03-25 2:50 ` Wen Congyang
2016-03-26 16:27 ` Max Reitz [this message]
2016-03-25 6:54 ` Wen Congyang
2016-03-26 16:33 ` Max Reitz
2016-03-28 15:25 ` Eric Blake
2016-03-29 15:29 ` Max Reitz
2016-03-29 15:39 ` Eric Blake
2016-03-29 15:43 ` Max Reitz
2016-03-29 15:51 ` [Qemu-devel] [RFC for-2.7 0/1] " Kevin Wolf
2016-03-29 15:56 ` Max Reitz
2016-03-29 16:09 ` Kevin Wolf
2016-03-29 16:10 ` Max Reitz
2016-03-30 12:43 ` [Qemu-devel] [Qemu-block] " Alberto Garcia
2016-03-30 14:22 ` Max Reitz
2016-03-31 9:49 ` Stefan Hajnoczi
2016-04-01 15:30 ` Max Reitz
2016-04-04 12:35 ` 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=56F6B85F.2090501@redhat.com \
--to=mreitz@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wency@cn.fujitsu.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).