[Top][All Lists]
[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
- Re: [Qemu-devel] [PATCH 00/10]: QError v4, (continued)
- Re: [Qemu-devel] [PATCH 00/10]: QError v4, Anthony Liguori, 2009/11/22
- Re: [Qemu-devel] [PATCH 00/10]: QError v4, Luiz Capitulino, 2009/11/23
- Re: [Qemu-devel] [PATCH 00/10]: QError v4, Anthony Liguori, 2009/11/23
- Re: [Qemu-devel] [PATCH 00/10]: QError v4, Luiz Capitulino, 2009/11/23
- Re: [Qemu-devel] [PATCH 00/10]: QError v4, Alexander Graf, 2009/11/23
- Re: [Qemu-devel] [PATCH 00/10]: QError v4, Luiz Capitulino, 2009/11/24
- Re: [Qemu-devel] [PATCH 00/10]: QError v4, Alexander Graf, 2009/11/24
- Re: [Qemu-devel] [PATCH 00/10]: QError v4, Markus Armbruster, 2009/11/23
- Re: [Qemu-devel] [PATCH 00/10]: QError v4, Luiz Capitulino, 2009/11/23
- Re: [Qemu-devel] [PATCH 00/10]: QError v4, Markus Armbruster, 2009/11/23
[Qemu-devel] Re: [PATCH 00/10]: QError v4,
Paolo Bonzini <=