qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 32/34] ram: refactor ram_save_block() return val


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 32/34] ram: refactor ram_save_block() return value
Date: Thu, 20 Dec 2012 16:42:29 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 12/19/2012 05:33 AM, Juan Quintela wrote:
> It could only return 0 if we only found dirty xbzrle pages that hadn't
> changed (i.e. they were written with the same content).  We don't care
> about that case, it is the same than nothing dirty.

s/than/as/

> 
> So now the return of the function is how much have it written, nothing

s/have/has/

> else. Adjust callers.
> 
> And we also made ram_save_iterate() return the number of transferred
> bytes, not the number of transferred pages.
> 
> Signed-off-by: Juan Quintela <address@hidden>
> ---
>  arch_init.c | 25 +++++++++++++++----------
>  1 file changed, 15 insertions(+), 10 deletions(-)
> 

>  static int ram_save_block(QEMUFile *f, bool last_stage)
> @@ -432,7 +431,7 @@ static int ram_save_block(QEMUFile *f, bool last_stage)
>      RAMBlock *block = last_seen_block;
>      ram_addr_t offset = last_offset;
>      bool complete_round = false;
> -    int bytes_sent = -1;
> +    int bytes_sent = 0;

Are we guaranteed that we will never send more than 2G bytes in one call
to this function, or should this be changed to int64_t?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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