qemu-devel
[Top][All Lists]
Advanced

[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.



reply via email to

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