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

[Blue Swirl]

On Wed, Jan 4, 2012 at 22:09, Anthony Liguori <address@hidden> wrote:
> 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.

IOTLB could be pushed to memory system, that way for example the TLB
could be shared between CPUs. Obviously each CPU needs individual
mappings.

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

The original reason was to avoid 64 bit arithmetic on 32 bit hosts.
Now that 128 bit arithmetic is used for memory API, it probably does
not make so much sense.

> Regards,
>
> Anthony Liguori
>
>>
>> -- PMM
>>
>
>