112ed241f5
The previous commit improved compile time by including less of the generated QAPI headers. This is impossible for stuff defined directly in qapi-schema.json, because that ends up in headers that that pull in everything. Move everything but include directives from qapi-schema.json to new sub-module qapi/misc.json, then include just the "misc" shard where possible. It's possible everywhere, except: * monitor.c needs qmp-command.h to get qmp_init_marshal() * monitor.c, ui/vnc.c and the generated qapi-event-FOO.c need qapi-event.h to get enum QAPIEvent Perhaps we'll get rid of those some other day. Adding a type to qapi/migration.json now recompiles some 120 instead of 2300 out of 5100 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180211093607.27351-25-armbru@redhat.com> [eblake: rebase to master] Signed-off-by: Eric Blake <eblake@redhat.com>
96 lines
3.6 KiB
Python
96 lines
3.6 KiB
Python
# -*- Mode: Python -*-
|
|
##
|
|
# = Introduction
|
|
#
|
|
# This document describes all commands currently supported by QMP.
|
|
#
|
|
# Most of the time their usage is exactly the same as in the user Monitor, this
|
|
# means that any other document which also describe commands (the manpage,
|
|
# QEMU's manual, etc) can and should be consulted.
|
|
#
|
|
# QMP has two types of commands: regular and query commands. Regular commands
|
|
# usually change the Virtual Machine's state someway, while query commands just
|
|
# return information. The sections below are divided accordingly.
|
|
#
|
|
# It's important to observe that all communication examples are formatted in
|
|
# a reader-friendly way, so that they're easier to understand. However, in real
|
|
# protocol usage, they're emitted as a single line.
|
|
#
|
|
# Also, the following notation is used to denote data flow:
|
|
#
|
|
# Example:
|
|
#
|
|
# | -> data issued by the Client
|
|
# | <- Server data response
|
|
#
|
|
# Please, refer to the QMP specification (docs/interop/qmp-spec.txt) for
|
|
# detailed information on the Server command and response formats.
|
|
#
|
|
# = Stability Considerations
|
|
#
|
|
# The current QMP command set (described in this file) may be useful for a
|
|
# number of use cases, however it's limited and several commands have bad
|
|
# defined semantics, specially with regard to command completion.
|
|
#
|
|
# These problems are going to be solved incrementally in the next QEMU releases
|
|
# and we're going to establish a deprecation policy for badly defined commands.
|
|
#
|
|
# If you're planning to adopt QMP, please observe the following:
|
|
#
|
|
# 1. The deprecation policy will take effect and be documented soon, please
|
|
# check the documentation of each used command as soon as a new release of
|
|
# QEMU is available
|
|
#
|
|
# 2. DO NOT rely on anything which is not explicit documented
|
|
#
|
|
# 3. Errors, in special, are not documented. Applications should NOT check
|
|
# for specific errors classes or data (it's strongly recommended to only
|
|
# check for the "error" key)
|
|
#
|
|
##
|
|
|
|
{ 'pragma': { 'doc-required': true } }
|
|
|
|
# Whitelists to permit QAPI rule violations; think twice before you
|
|
# add to them!
|
|
{ 'pragma': {
|
|
# Commands allowed to return a non-dictionary:
|
|
'returns-whitelist': [
|
|
'human-monitor-command',
|
|
'qom-get',
|
|
'query-migrate-cache-size',
|
|
'query-tpm-models',
|
|
'query-tpm-types',
|
|
'ringbuf-read' ],
|
|
'name-case-whitelist': [
|
|
'ACPISlotType', # DIMM, visible through query-acpi-ospm-status
|
|
'CpuInfoMIPS', # PC, visible through query-cpu
|
|
'CpuInfoTricore', # PC, visible through query-cpu
|
|
'QapiErrorClass', # all members, visible through errors
|
|
'UuidInfo', # UUID, visible through query-uuid
|
|
'X86CPURegister32', # all members, visible indirectly through qom-get
|
|
'q_obj_CpuInfo-base' # CPU, visible through query-cpu
|
|
] } }
|
|
|
|
# Documentation generated with qapi-gen.py is in source order, with
|
|
# included sub-schemas inserted at the first include directive
|
|
# (subsequent include directives have no effect). To get a sane and
|
|
# stable order, it's best to include each sub-schema just once, or
|
|
# include it first in qapi-schema.json.
|
|
|
|
{ 'include': 'qapi/common.json' }
|
|
{ 'include': 'qapi/sockets.json' }
|
|
{ 'include': 'qapi/run-state.json' }
|
|
{ 'include': 'qapi/crypto.json' }
|
|
{ 'include': 'qapi/block.json' }
|
|
{ 'include': 'qapi/char.json' }
|
|
{ 'include': 'qapi/net.json' }
|
|
{ 'include': 'qapi/rocker.json' }
|
|
{ 'include': 'qapi/tpm.json' }
|
|
{ 'include': 'qapi/ui.json' }
|
|
{ 'include': 'qapi/migration.json' }
|
|
{ 'include': 'qapi/transaction.json' }
|
|
{ 'include': 'qapi/trace.json' }
|
|
{ 'include': 'qapi/introspect.json' }
|
|
{ 'include': 'qapi/misc.json' }
|