qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 07/10] ram_save_remaining() returns an uint64_t


From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH 07/10] ram_save_remaining() returns an uint64_t
Date: Tue, 30 Nov 2010 15:38:45 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Anthony Liguori <address@hidden> wrote:
> On 11/23/2010 05:03 PM, Juan Quintela wrote:
>> From: Juan Quintela<address@hidden>
>>
>> It returns a counter of things, not a ram address.
>>
>> Signed-off-by: Juan Quintela<address@hidden>
>> Signed-off-by: Juan Quintela<address@hidden>
>> ---
>>   arch_init.c |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch_init.c b/arch_init.c
>> index df3d91f..9e941a0 100644
>> --- a/arch_init.c
>> +++ b/arch_init.c
>> @@ -173,10 +173,10 @@ static int ram_save_block(QEMUFile *f)
>>
>>   static uint64_t bytes_transferred;
>>
>> -static ram_addr_t ram_save_remaining(void)
>> +static uint64_t ram_save_remaining(void)
>>   {
>>       RAMBlock *block;
>> -    ram_addr_t count = 0;
>> +    uint64_t count = 0;
>>
>>       QLIST_FOREACH(block,&ram_list.blocks, next) {
>>           ram_addr_t addr;
>>    
>
> No, it returns a count of bytes of ram which is a subset of
> ram_addr_t's space.  The unit is definitely right here.

I thought this would be un-controversial.  But the important part from
your sentence is "count".  ram_addr_t is an addr in my mind.

  /* address in the RAM (different from a physical address) */
  typedef unsigned long ram_addr_t;

in cpu-common.h comment, it is also an address.  But doing more grepping
I see that it is "conveniently" used as a size in other places.

Later, Juan.

> Regards,
>
> Anthony Liguori



reply via email to

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