qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] use an unsigned long for the max_sz parameter i


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH] use an unsigned long for the max_sz parameter in load_image_targphys
Date: Mon, 12 Mar 2012 17:14:44 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2

Am 12.03.2012 17:04, schrieb Alexander Graf:
> 
> On 12.03.2012, at 16:53, Markus Armbruster wrote:
> 
>> Peter Maydell <address@hidden> writes:
>>
>> [...]
>>> Putting a "restrict to INT_MAX" in the highbank code is definitely
>>> wrong (not least because passing values to load_image_targphys isn't
>>> the only thing we use that field in arm_boot_info for!)
>>> The ARM boot code needs updating because it shouldn't be
>>> using 'int' for arm_boot_info.ram_size, and using target_phys_addr_t
>>> the same as we do for initrd_size is the obvious thing. I have no
>>> particular objection to having some new target_phys_size_t or whatever,
>>> and I could be persuaded that we should follow the memory API in
>>> using uint64_t for sizes, but it needs to be a type that either follows
>>> guest phys addr restrictions or a fixed-width type which we have decreed
>>> is always large enough,
>>
>> There is already a type that is defined to be wide enough for any object
>> size: size_t.
>>
>>>                        not a type which varies based on host properties.
>>
>> To be honest, the whole debate feels like bikeshedding to me.  Yes,
>> load_image_targphys()'s argument max_sz is the size of a slice of guest
>> memory.  It's also the size of a host object, allocated with g_malloc0()
>> in rom_add_file().  It's also the size of a disk file.
>>
>> I'd make it size_t and be done with it.  If you absolutely must
>> overengineer things, go ahead and create a new type for target sizes.  I
>> doubt making it wider than size_t will work in practice without a lot of
>> hoop jumping, though.
> 
> I agree. Let's end this discussion and use the biggest variable type we 
> support for addresses: uint64_t. That way we have host independent 
> predictability, but don't use _addr_t types which Andreas seems to dislike.

Fine with me.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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