qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-block] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree


From: Max Reitz
Subject: [Qemu-block] [RFC for-2.7 0/1] block/qapi: Add query-block-node-tree
Date: Thu, 24 Mar 2016 20:07:17 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]