Re: [Qemu-devel] [PATCH 00/10]: QError v4

[Anthony Liguori <anthony@codemonkey.ws>]

Markus Armbruster wrote:
> I'm thinking and talking primarily about the protocol, and that probably
> makes me too terse on implementation.
>
> I didn't mean to suggest that for adding the data part we should add new
> arguments providing the data.  That would be dumb indeed.
>
> Instead, I'd like to start with an extremely simple error reporting
> mechanism, which requires an equally simple conversion, namely from
> monitor_printf("human-readable error") to something of the form
> qmp_error(error_code, "human-readable error").
>   

This is what I want to focus on because I think everything just boils 
down to this. Namely:

qmp_error(error_code, "human-readable error");

In my mind, the purpose of QMP is to provide a machine readable form of 
the monitor protocol. We have a monitor protocol today but because it's 
written as free-form text (often English sentences), it's 
difficult/impossible to parse which makes managing qemu extremely 
difficult. We have problems with escaping characters, use of 
non-deterministic grammars, etc.

What I'm fundamentally opposed to is the "human-readable error" part of 
your proposal because it's free-form and unstructured. It has all the 
same problems as the current monitor interface. I'm opposed to this for 
the same reason I would be opposed to an "info balloon" command output of:

{"data" : {"target" : "The guest has 32MB of memory"}}

If all you were doing is outputting "info balloon" to a user in a 
command line tool, sure, this would be easier for the client to deal 
with. However, the whole purpose of QMP is to allow tools to make sense 
out of the monitor commands.

The contents of an error are just as important as the output of a 
command. The error code helps a bit but the problem with a qmp_error() 
that takes a string parameter is that there is additional information in 
that string that is inaccessible to a client.

I'm certainly willing to consider alternative ways to do qmp_error() but 
taking a free form string is not an option in my mind. It goes against 
the fundamentals of what we're trying to build with QMP.

So if you're opposed to structured error data, just having 
qmp_error(error_code) is a reasonable alternative. I don't think it's 
the right thing to do, but I think it's still within the spirit of the 
goals of QMP.

I think this is the fundamental thing to come to an agreement on in this 
discussion before we can even delve into the merits or lack thereof of 
structured error data.

Regards,

Anthony Liguori