qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Rename target_phys_addr_t to Phys


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] Rename target_phys_addr_t to Phys
Date: Wed, 04 Jan 2012 16:09:23 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

On 01/04/2012 01:50 PM, Peter Maydell wrote:
On 4 January 2012 19:32, Avi Kivity<address@hidden>  wrote:
The name 'Phys' conveys exactly the same information as 'target_phys_addr_t':

  - it has to be a physical address (no such thing as physical data)
  - it has to be a target address (qemu doesn't do host physical addresses)
  - the fact that it's a type is implied by the naming convention

As it's 4 characters vs. 18, and C standard compliant to boot, Phys is a
clear winner.  Rename all instances of target_phys_addr_t to the new name.
All hail Phys!

  323 files changed, 1959 insertions(+), 1959 deletions(-)

Seems like gratuitous churn to me...

Agreed.  I don't really like using CamelCase for scalar values either.

target_phys_addr_t should exist IMHO in the device model code. I think it would be more useful to introduce a hw_addr, fix it at u64, make the device model and memory API use that, and then make it so we didn't do the silliness around libhw32/libhw64.

I think the only reason we don't fix target_phys_addr_t at u64 is because of sensitivity around the TLB softmmu, right? A hw_addr for hw/*.c should be a reasonable compromise.

Making the build faster (by killing libhw32/libhw64) would be a good justification for this type of change IMHO.

Regards,

Anthony Liguori


-- PMM





reply via email to

[Prev in Thread] Current Thread [Next in Thread]