mirror of
https://github.com/xemu-project/xemu.git
synced 2024-11-23 19:49:43 +00:00
abb3d37d0c
In my "build everything" tree, changing a type in qapi/common.json triggers a recompile of some 3600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). One common dependency is QapiErrorClass: it's used only in in qapi/error.h, which uses nothing else, and is widely included. Move QapiErrorClass from common.json to new error.json. Touching common.json now recompiles only some 2900 objects. Cc: Eric Blake <eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-4-armbru@redhat.com>
109 lines
4.0 KiB
Python
109 lines
4.0 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
|
|
'BlockdevVmdkSubformat', # all members, to match VMDK spec spellings
|
|
'BlockdevVmdkAdapterType', # legacyESX, to match VMDK spec spellings
|
|
'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 right here.
|
|
|
|
{ 'include': 'error.json' }
|
|
{ 'include': 'common.json' }
|
|
{ 'include': 'sockets.json' }
|
|
{ 'include': 'run-state.json' }
|
|
{ 'include': 'crypto.json' }
|
|
{ 'include': 'block.json' }
|
|
{ 'include': 'char.json' }
|
|
{ 'include': 'dump.json' }
|
|
{ 'include': 'job.json' }
|
|
{ 'include': 'net.json' }
|
|
{ 'include': 'rdma.json' }
|
|
{ 'include': 'rocker.json' }
|
|
{ 'include': 'tpm.json' }
|
|
{ 'include': 'ui.json' }
|
|
{ 'include': 'authz.json' }
|
|
{ 'include': 'migration.json' }
|
|
{ 'include': 'transaction.json' }
|
|
{ 'include': 'trace.json' }
|
|
{ 'include': 'introspect.json' }
|
|
{ 'include': 'qom.json' }
|
|
{ 'include': 'qdev.json' }
|
|
{ 'include': 'machine.json' }
|
|
{ 'include': 'machine-target.json' }
|
|
{ 'include': 'misc.json' }
|
|
{ 'include': 'misc-target.json' }
|
|
{ 'include': 'audio.json' }
|