Anthony Liguori <anth...@codemonkey.ws> wrote: > On 11/23/2010 05:03 PM, Juan Quintela wrote: >> From: Juan Quintela<quint...@trasno.org> >> >> It returns a counter of things, not a ram address. >> >> Signed-off-by: Juan Quintela<quint...@trasno.org> >> Signed-off-by: Juan Quintela<quint...@redhat.com> >> --- >> 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