[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 00/10]: QError v4
Date: Sun, 22 Nov 2009 10:08:16 -0600
User-agent: Thunderbird (X11/20090825)

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.


Anthony Liguori

reply via email to

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