Andrea Arcangeli wrote:
On Sat, Dec 13, 2008 at 10:46:49AM -0600, Anthony Liguori wrote:
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.
If you take a size_t, then all callers have to validate that the size
they're passing in (which may originate from the guest), is not going to
cause an overflow. You will naturally validate this in the map()
function because you cannot map something that is greater than can fit
in a void *. All callers have to handle the case where return is NULL
from map() which means that you can fold this error checking into map()
without the callers having to even think of it.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
