[Top][All Lists]

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

Re: [PATCH v3 05/19] docs/devel: document expectations for HMP commands

From: Markus Armbruster
Subject: Re: [PATCH v3 05/19] docs/devel: document expectations for HMP commands in the future
Date: Thu, 28 Oct 2021 16:47:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Daniel P. Berrangé <berrange@redhat.com> writes:

> 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
> prefix.
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>  docs/devel/writing-monitor-commands.rst | 8 ++++++++
>  1 file changed, 8 insertions(+)
> diff --git a/docs/devel/writing-monitor-commands.rst 
> b/docs/devel/writing-monitor-commands.rst
> index 82a382d700..8fb855e192 100644
> --- a/docs/devel/writing-monitor-commands.rst
> +++ b/docs/devel/writing-monitor-commands.rst
> @@ -11,6 +11,14 @@ 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.
> +New commands may be implemented in QMP only.  New HMP commands should be
> +implemented on top of QMP.  The typical HMP command wraps around an
> +equivalent QMP command, but HMP convenience commands built from QMP
> +building blocks are also fine.  The long term goal is to make all
> +existing HMP commands conform to this, to fully isolate HMP from the
> +internals of QEMU. Refer to the `Writing a debugging aid returning
> +unstructured text`_ section for further guidance on commands that
> +would have traditionally been HMP only.
>  Overview
>  --------

Reviewed-by: Markus Armbruster <armbru@redhat.com>

reply via email to

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