Am 12.03.2012 17:04, schrieb Alexander Graf: > > On 12.03.2012, at 16:53, Markus Armbruster wrote: > >> Peter Maydell <peter.mayd...@linaro.org> 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
