[Top][All Lists]

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

[PATCH v2 05/53] docs/devel: document expectations for HMP commands in t

From: Daniel P . Berrangé
Subject: [PATCH v2 05/53] docs/devel: document expectations for HMP commands in the future
Date: Tue, 14 Sep 2021 15:19:54 +0100

We no longer wish to have commands implemented in HMP only. All commands
should start with a QMP implementation and the HMP merely be a shim
around this. To reduce the burden of implementing QMP commands where
there is low expectation of machine usage, requirements for QAPI
modelling are relaxed provided the command is under the "x-" name

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
 docs/devel/writing-monitor-commands.rst | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/docs/devel/writing-monitor-commands.rst 
index 4cf51ab557..983130a793 100644
--- a/docs/devel/writing-monitor-commands.rst
+++ b/docs/devel/writing-monitor-commands.rst
@@ -11,6 +11,16 @@ For an in-depth introduction to the QAPI framework, please 
refer to
 docs/devel/qapi-code-gen.txt. For documentation about the QMP protocol,
 start with docs/interop/qmp-intro.txt.
+Historically QEMU has permitted new monitor commands to be implemented in HMP
+only, QMP only, or both, depending on whether they needed to be accessible to
+human operators, machines, or both. When both QMP and HMP are implemented it
+is expected the HMP implementation is a shim around the QMP implementation.
+Going forward, the expectation is that new commands are implemented in QMP
+only, or both QMP and HMP. No further commands are to be added to HMP only.
+The long term goal is that all HMP commands will be implemented in terms of
+their QMP equivalent, enabling internals of QEMU to be fully isolated from
+the HMP implementation. Refer to the later topic on modelling data in QAPI
+for further guidance on commands that would have traditionally been HMP only.

reply via email to

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