From: Anthony Liguori <anthony@codemonkey.ws>
To: Jes Sorensen <Jes.Sorensen@redhat.com>
Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH v3] Improve error handling in do_snapshot_blkdev()
Date: Tue, 08 Mar 2011 11:46:23 -0600 [thread overview]
Message-ID: <4D766B6F.9060307@codemonkey.ws> (raw)
In-Reply-To: <4D765CFF.3090909@redhat.com>
On 03/08/2011 10:44 AM, Jes Sorensen wrote:
> On 03/08/11 14:42, Anthony Liguori wrote:
>> On 03/08/2011 02:24 AM, Jes Sorensen wrote:
>>> On 03/07/11 18:47, Anthony Liguori wrote:
>>>> In your case, it's definitely a fatal error for the command. The
>>>> command is failing and you're just printing out information about the
>>>> rollback information you're taking.
>>> I guess the disconnect here is the definition of fatal. Fatal in my book
>>> means we're dead, toast, gone ..... hardly the case if we manage to fail
>>> back to the previous image.
>> Let me put it another way, you can't call qerror_report twice because
>> there is only one QMP error object sent in the protocol. You
>> potentially call qerror_report twice which breaks QMP.
>>
>> The way you ought to structure things is to return to the old image, and
>> then throw an error saying that you couldn't open the new image.
> I see, I had the impression QMP would create multiple objects and pass
> them along. Guess not.
No, this is made clearer in QAPI because an error pointer is passed and
you explicitly set the object.
>> If FileOpenFailed has the filename of the new image, then opening the
>> file failed and we're using the old image. If FileOpenFailed has the
>> filename of the old image, we're toast.
>>
>> That basically covers it, no?
> It kinda sorta covers it. The problem with that is that you then have to
> do a string match of the return values to determine which of the cases
> happened, which isn't very nice. But I guess we can do that for now.
Right, but this can be done in the HMP command such that the HMP command
still prints out the warning message.
The key is to have well documented error semantics where the various
cases can be distinguished because then we can ensure that we can not
only print out a nice error message in HMP, but that a remote QMP client
(like libvirt) can also generate a high quality error message.
Regards,
Anthony Liguori
> I'll have a look.
>
> Cheers,
> Jes
>
next prev parent reply other threads:[~2011-03-08 17:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-07 15:27 [Qemu-devel] [PATCH v3] Improve error handling in do_snapshot_blkdev() Jes.Sorensen
2011-03-07 15:44 ` [Qemu-devel] " Kevin Wolf
2011-03-07 16:34 ` [Qemu-devel] " Anthony Liguori
2011-03-07 16:39 ` Jes Sorensen
2011-03-07 17:47 ` Anthony Liguori
2011-03-08 8:24 ` Jes Sorensen
2011-03-08 13:42 ` Anthony Liguori
2011-03-08 16:44 ` Jes Sorensen
2011-03-08 17:46 ` Anthony Liguori [this message]
2011-03-09 10:20 ` Jes Sorensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D766B6F.9060307@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=Jes.Sorensen@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).