[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC] error: Include hint everywhere
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH RFC] error: Include hint everywhere |
Date: |
Tue, 19 Dec 2017 15:29:15 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Adding Eric for additonal QMP design expertise.
Fam Zheng <address@hidden> writes:
> Previously we only print hint lines if we are in a command line context
> or HMP. However QMP errors are also eventually consumed by human and the
> hint could help.
>
> Append hint lines already in error_get_pretty() and do as said above
> consistently in CLI, HMP and QMP.
>
> Signed-off-by: Fam Zheng <address@hidden>
Problematic.
The intended use of the "hint" feature is to add hints on the *human*
user interface. These need not make sense for QMP, which has different
syntax. Please see
http://lists.gnu.org/archive/html/qemu-devel/2017-08/msg01991.html
(which I let fall through the cracks, sorry about that).
In practice, we've been using / abusing the feature for other purposes,
too, i.e. hints that do make sense for QMP.
If we decide we want to transmit such hints via QMP, we need to decide
how to (more on that below), and we need to examine the existing hints
one by one to decide whether they make sense for QMP.
If we determine that all of the existing hints make sense for QMP, and
expect that all future hints will, then we can repurpose
error_append_hint(). Else, we need two functions, one for each kind of
hint.
On to QMP design. Quote qmp-spec.txt:
2.4.2 error
-----------
The format of an error response is:
{ "error": { "class": json-string, "desc": json-string }, "id": json-value }
Where,
- The "class" member contains the error class name (eg. "GenericError")
- The "desc" member is a human-readable error message. Clients should
not attempt to parse this message.
- The "id" member contains the transaction identification associated with
the command execution if issued by the Client
Your patch changes "desc" from a short(ish) message without newline to a
multi-line message that may or may not end with a newline (I think).
Is that a good idea?
The conservative way to add hints is a new optional member.