On 01/04/2012 01:50 PM, Peter Maydell wrote:
On 4 January 2012 19:32, Avi Kivity<a...@redhat.com> 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
