Re: [Qemu-devel] KVM call agenda for tuesday 31

[Avi Kivity]

On 03/05/2012 05:15 PM, Anthony Liguori wrote:
>> The other alternative is to s/target_phys_addr_t/uint64_t/ in the memory
>> API.  I think 32-on-32 is quite rare these days, so it wouldn't be much
>> of a performance issue.
>
>
> I think this makes sense independent of other discussions regarding
> fixing target_phys_addr_t size.
>
> Hardware addresses should be independent of the target.  If we wanted
> to use a hw_addr_t that would be okay too.
>

Would this hw_addr (s/_t$//, or you'll be Blued) be fixed at uint64_t
(and thus only documentary), or also subject to multiple compilation?

-- 
error compiling committee.c: too many arguments to function