qemu-devel
[Top][All Lists]
Advanced

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

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


From: Paolo Bonzini
Subject: [Qemu-devel] Re: [PATCH 00/10]: QError v4
Date: Wed, 18 Nov 2009 19:13:38 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Lightning/1.0pre Thunderbird/3.0b4


2. It falls short of the requirement that clients can reasonably
    classify errors they don't know.

True. (Though adding a classification mechanism can be done later once we have an idea of what errors are there at all).

3. It falls short of the requirement that clients can easily present a
    human-readable error description to their human users, regardless of
    whether they know the error or not.

That's true. I would definitely have the interpolated desc field go on the wire too, as part of the JSON form of QError.

If I understand Dan correctly, machine-readable error code +
human-readable description is just fine, as long as the error code is
reasonably specific and the description is precise and complete.  Have
we heard anything else from client developers?

Then (except for the asynchronicity) the current qemu monitor protocol is also just fine, including the fact that we send migrate and get m\rmi\rmig\rmigr etc. back on the socket.

"error while creating snapshot on '%s'" may be easy to parse, but looking at a dictionary field in { "filename" : "blah.img" } is easier, and at the same time solves issues with escaping weird characters in the file name.

* The crucial question for the client isn't "what exactly went wrong".
   It is "how should I handle this error".  Answering that question
   should be easy (say, check the error code).  Figuring out what went
   wrong should still be possible for a human operator of the client.

The same error can be handled in a different way depending on the situation. A missing image is in general a fatal error, but maybe another client could create images on the fly.

Based on what I've learned about client requirements so far, I figure
that solution is "easily classified error code + human-readable
description".

How would you classify the error code? By subsystem or by (for example) severity or anything else? Does QEMU have subsystems that are well-identified enough to be carved in stone in QError? (All genuine questions. I have no idea).

Paolo





reply via email to

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