[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: Fri, 20 Nov 2009 13:04:52 -0600
User-agent: Thunderbird (X11/20090825)

Markus Armbruster wrote:
We have:

(1) machine-readable error code

(2) human-readable error message

(3) machine-readable additional error data

The old monitor prints just (3).


You propose to have QMP send (1) and (3).  This forces all clients to
come up with (2) themselves.  Why that's problematic is discussed
elsewhere in this thread.

As I said else where, sending (2) along with (1) and (3) doesn't bother me. It's whether (2) is generated automatically from (1) and (2) or whether within qemu, the caller who creates the error supplies that text free hand. That's what I'm fundamentally opposed to.

Imagine we already had a QMP that sent (1) and (2), encoded in JSON.
Then nothing could stop you to add a "data" part holding (3).

If (2) is generated from (1) based on a table, then I agree with you. If (2) is open coded, then I disagree fundamentally because you're mixing in information from (3) in there.

keeping things simple by sending just (1) and (2) now does not make it
impossible to send (3) later, hence does not make it impossible to
provide your important feature in a future iteration.

Let me give a concrete example of where your logic falls apart. Say you start out with:

qemu_error_new(QERR_DEVICE_NOT_READY, "Ballooning is not enabled in the guest");

And somewhere else you have:

qemu_error_new(QERR_DEVICE_NOT_READY, "The virtio-net driver is not loaded in the guest");

There is no way to unify these into a coherent message. It's forever free form and the there will always be additional information in the description that requires parsing from a client. This is obviously more complicated for the client. It's also impossible to internationalize effectively because even if you introduce a data field, you aren't passing enough information to generate these messages. In this case, it's a subtle case of grammatical mismatch although both messages are saying the exact same thing.

An error it doesn't know about is a bug in the application.  Adding a
new type of error to a monitor function is equivalent to changing it's
behavior.  It should require a versioning change.

What do you mean by versioning change?  And what does it mean for

We really haven't gotten into versioning/feature negotation, but in my mind, if we add a new error type for a function, that's the same as adding an additional argument. It's a new feature that requires some sort of version/feature mechanism.

My basic concerns boil down to:

1) It must be possible to support localization from the very beginning

If you insist on supporting localization in the client right now,
despite costs & risks, there's nothing I can do, and nothing more for me
to say on my first concern (QMP overengineered for a first iteration of
the protocol).

Your proposal makes it impossible forever so yes, it's a hard requirement. I'm making a lot of attempts to meet you half way but if your argument is "I don't like this, it's too complicated, I don't care about localization" then I don't think we're going to get over that.


Anthony Liguori

reply via email to

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