From: Max Reitz <mreitz@redhat.com>
To: qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: [Qemu-devel] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree
Date: Thu, 24 Mar 2016 20:07:17 +0100 [thread overview]
Message-ID: <1458846438-28573-1-git-send-email-mreitz@redhat.com> (raw)
As I responded to:
- http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg04464.html
- http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg05680.html
I think a general solution for querying the block node tree would be
nice (I don't think we actually have one). The single patch in this
series implements such a command.
However, this is an RFC because I'm not sure whether we really want this
and thus I didn't want to write the necessary tests for something we may
be going to discard anyway.
There are two reasons why I fear we may not want this:
The first is that the node graph is more or less something internal to
qemu. Its actual structure may (and most probably will) change over
time. We do want to be able to let the user or management application
manage the graph in fine detail, but these modifications are something
that can be emulated by legacy handling code later if we decide they are
no longer in line with the internal graph that we'd like to have.
However, if we emit the full graph with a command such as introduced
here, we can hardly change its outside appearance just to please legacy
applications. The output will change if the internal representation
changes.
I don't personally think this is too bad as long as we clearly state
this in the command's description: That qemu is free to implicitly
create intermediate nodes the user did not explicitly specify, and that
the set of nodes thus created may change over time.
No, I didn't specify this in this version, but it's an RFC, after all.
:-)
The second reason why I think we may not want this command: The known
unknowns. Everything that somehow allows the user to touch or see the
node graph may have some legacy implications later that right now I
fail to foresee.
And besides the known knowns and the known unknowns, there are of course
the unknown unknowns, but these exist with any patch.
In case you're wondering, a sample QMP invocation looks like this:
$ x86_64-softmmu/qemu-system-x86_64 \
-drive if=none,id=drive,node-name=raw,driver=raw,\
file.node-name=quorum,file.driver=quorum,\
file.children.0.driver=null-co,\
file.children.0.node-name=null0,\
file.children.1.driver=null-co,\
file.children.1.node-name=null1,\
file.vote-threshold=1 \
-qmp-pretty stdio -nodefaults
[...]
{'execute':'query-block-node-tree','arguments':{'root-node':'drive'}}
{
"return": {
"children": [
{
"role": "file",
"node": {
"children": [
{
"role": "children.1",
"node": {
"children": [
],
"node-name": "null1"
}
},
{
"role": "children.0",
"node": {
"children": [
],
"node-name": "null0"
}
}
],
"node-name": "quorum"
}
}
],
"node-name": "raw"
}
}
Max
Max Reitz (1):
block/qapi: Add query-block-node-tree
block/qapi.c | 43 +++++++++++++++++++++++++++++++++++++++++++
qapi/block-core.json | 46 ++++++++++++++++++++++++++++++++++++++++++++++
qmp-commands.hx | 38 ++++++++++++++++++++++++++++++++++++++
3 files changed, 127 insertions(+)
--
2.7.4
next reply other threads:[~2016-03-24 19:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-24 19:07 Max Reitz [this message]
2016-03-24 19:07 ` [Qemu-devel] [RFC for-2.7 1/1] block/qapi: Add query-block-node-tree Max Reitz
2016-03-25 2:50 ` Wen Congyang
2016-03-26 16:27 ` Max Reitz
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=1458846438-28573-1-git-send-email-mreitz@redhat.com \
--to=mreitz@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).