Am 10.03.2012 14:51, schrieb Peter Maydell: > On 9 March 2012 18:47, Andreas Färber <afaer...@suse.de> wrote: >> Am 09.03.2012 18:11, schrieb Peter Maydell: >>> On 9 March 2012 14:28, Andreas Färber <afaer...@suse.de> wrote: >>>> No, please. We're describing sizes, not addresses. target_phys_addr_t >>>> thus is semantically wrong here. The RAM size is unsigned long IIRC (it >>>> is limited by the host's available memory). If you subtract something >>>> from a size it remains a size. I had therefore suggested size_t before. >>>> I expect sizeof(size_t) >= sizeof(unsigned long). >>> >>> We're discussing target sizes. size_t might be smaller than >>> target_phys_addr_t, so it's also semantically wrong. We don't >>> have a target_size_t, though, and I think "use an address >>> related type for an offset" is less bad than "use a host >>> sized type for a guest sized value". >> >> That is a moot point. There is no such thing as a "target size". > > "Length of a block of memory on the guest" is what I meant. > What you need is "an integer type large enough to hold the > difference between two guest pointer values". The size of > that type should depend only on the guest config, not on the > host, so 'unsigned long', 'size_t', 'off_t' etc are all wrong.
Your view is very ARM-centric. In the PowerPC domain for instance, we have a number of usages where we hardcode a size of, e.g., 1 MB. And Alex should know that. I don't want to use target_phys_addr_t for that and forcing an end address calculation, as suggested by Alex, would be possible but is not as convenient as the current API. Doing a size check as Mark has demonstrated in ARM code (one place!) seems much simpler to me than hurting all targets just because ARM wants to pass a possibly stupid value unchecked to the common API. Compare David's off_t patch from March 8th: We'll never get an image size larger than off_t's max. Using target_phys_addr_t, uint64_t or __int128_t for the max are all moot (academic) because we'll never get to their max if it's larger than off_t. Therefore I've been saying, the host's limit is the upper realistic limit for image_load_targphys(). ELF may be a different case to consider since it can be sparse. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
