|
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
[Prev in Thread] | Current Thread | [Next in Thread] |