On Sat, Dec 13, 2008 at 10:46:49AM -0600, Anthony Liguori wrote: > Andrea Arcangeli wrote: >> On Fri, Dec 12, 2008 at 01:15:13PM -0600, Anthony Liguori wrote: >> >>> void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t size, >>> int is_write); >>> >> >> Just a side note (doesn't mean I agree with the above), it doesn't >> make sense to use an ram_addr_t size when you return a 32bit address >> on 32bit qemu build. >> > > size_t is completely wrong for 64-bit targets on 32-bit hosts. ram_addr_t > is the type we use for guest ram size. It's 64-bit all of the time simply > because it's easier to do that and we decided that the little bit of wasted > space/computations were not a problem.
Not sure why you think I'm suggesting you to use size_t. I'm just trying to tell you that if you insist in this 64bit-guest-on-32bit-host-is-dead-and-obsolete-to-support (i.e. if you pass a ram_addr_t size to cpu_physical_memory_map) you've at least to return ram_addr_t too). 'void *' is like size_t so the above API getting ram_addr_t length and returning 'void *', can't possibly be sane. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
