From: Paolo Bonzini <pbonzini@redhat.com>
To: quintela@redhat.com
Cc: anthony@codemonkey.ws, Lei Li <lilei@linux.vnet.ibm.com>,
mrhines@linux.vnet.ibm.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/3 resend v2] arch_init: right return for ram_save_iterate
Date: Wed, 11 Sep 2013 13:27:36 +0200 [thread overview]
Message-ID: <523053A8.4000009@redhat.com> (raw)
In-Reply-To: <8738pb39ed.fsf@elfo.elfo>
Il 11/09/2013 13:06, Juan Quintela ha scritto:
>>> And I think that the right solution is make qemu_get_rate_limit() to
>>> return -1 in case of error (or the error, I don't care).
>>
>> You might do both things, it would avoid the useless g_usleep you
>> pointed out below. But Lei's patch is good, because an error could
>> happen exactly during the qemu_put_be64 that writes RAM_SAVE_FLAG_EOS.
>
> Caller checks also. This is the reason I wanted qemu_file_* callers to
> return an error. It has some advantages and some disadvantages. We
> don't agree on which ones are bigger O:-)
I think the disadvantages are bigger. It litters the code with error
handling, hides where things actually happen, and doesn't even simplify
QEMUFile itself. Checking only at the toplevel is simpler, all we need
to do is ensure that we get there every now and then (and that's what
qemu_file_rate_limit does).
>>> savevm.c: qemu_savevm_state_iterate()
>>>
>>> if (qemu_file_rate_limit(f)) {
>>> return 0;
>>> }
>>>
>>> check is incorrect again, we should return an error if there is one
>>> error.
>>
>> Nothing cares if qemu_savevm_state_iterate returns 0 or negative, so
>> changing qemu_savevm_state_iterate to only return 0/1 would make sense too.
>
> In this case, 0 means:
> please, call us again
> when what we mean is:
> don't care about calling us again, there is an error. Handle the error.
Or alternatively, 0 means:
we haven't finished the work
when what we mean is:
we haven't finished the work (BTW, please check if there is an error)
> Notice that qemu_save_iterate() already returns errors in other code
> paths
Yes that's also unnecessary.
> If we change th ereturn value for qemu_file_rate_limit() the change that
> cames with this patch is not needed, that was my point.
This is what an earlier patch from Lei did. I told him (or her?) to
leave qemu_file_rate_limit aside since the idea behind QEMUFile is to
only handle the error at the top.
Paolo
next prev parent reply other threads:[~2013-09-11 11:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-04 9:02 [Qemu-devel] [PATCH 0/3 resend v2] Migration fix Lei Li
2013-09-04 9:02 ` [Qemu-devel] [PATCH 1/3 resend v2] savevm: add comments for qemu_file_get_error() Lei Li
2013-09-11 8:52 ` Juan Quintela
2013-09-04 9:02 ` [Qemu-devel] [PATCH 2/3 resend v2] savevm: fix wrong initialization by ram_control_load_hook Lei Li
2013-09-04 9:02 ` [Qemu-devel] [PATCH 3/3 resend v2] arch_init: right return for ram_save_iterate Lei Li
2013-09-11 9:17 ` Juan Quintela
2013-09-11 9:32 ` Paolo Bonzini
2013-09-11 11:06 ` Juan Quintela
2013-09-11 11:27 ` Paolo Bonzini [this message]
2013-09-12 7:11 ` Lei Li
2013-09-12 7:47 ` Orit Wasserman
2013-09-04 12:49 ` [Qemu-devel] [PATCH 0/3 resend v2] Migration fix Orit Wasserman
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=523053A8.4000009@redhat.com \
--to=pbonzini@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=lilei@linux.vnet.ibm.com \
--cc=mrhines@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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).