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

[malc]

On Mon, 5 Mar 2012, Blue Swirl wrote:

> On Mon, Mar 5, 2012 at 15:17, Avi Kivity <address@hidden> wrote:
> > 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
> 
> Malced? Posixed?

Heh, a_moo would be Malced, no _t is Posixed indeed.

-- 
mailto:address@hidden