From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33896 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Px0zL-0006XL-Kn for qemu-devel@nongnu.org; Tue, 08 Mar 2011 12:46:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Px0zJ-0001jW-RO for qemu-devel@nongnu.org; Tue, 08 Mar 2011 12:46:27 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:40219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Px0zJ-0001jB-M0 for qemu-devel@nongnu.org; Tue, 08 Mar 2011 12:46:25 -0500 Received: by iym7 with SMTP id 7so6150044iym.4 for ; Tue, 08 Mar 2011 09:46:24 -0800 (PST) Message-ID: <4D766B6F.9060307@codemonkey.ws> Date: Tue, 08 Mar 2011 11:46:23 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v3] Improve error handling in do_snapshot_blkdev() References: <1299511653-11357-1-git-send-email-Jes.Sorensen@redhat.com> <4D75092F.1020107@codemonkey.ws> <4D750A4B.1070304@redhat.com> <4D751A2E.7030309@codemonkey.ws> <4D75E7D0.90900@redhat.com> <4D76323D.8050906@codemonkey.ws> <4D765CFF.3090909@redhat.com> In-Reply-To: <4D765CFF.3090909@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.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 >