qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/5] hw/pxa2xx_lcd.c: drop VMSTATE_UINTTL usage


From: Mitsyanko Igor
Subject: Re: [Qemu-devel] [PATCH 3/5] hw/pxa2xx_lcd.c: drop VMSTATE_UINTTL usage
Date: Wed, 22 Feb 2012 16:26:20 +0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19

On 02/22/2012 03:36 PM, andrzej zaborowski wrote:
On 22 February 2012 11:15, Igor Mitsyanko<address@hidden>  wrote:
Convert three variables in DMAChannel state from type target_phys_addr_t to 
uint32_t,
use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables.
We can do it safely because:
1) pxa2xx has 32-bit physical address;
2) rest of the code in this file treats these variables as uint32_t;

Why's uint32_t more correct though?  The purpose of using a named type
across qemu is to mark fields as memory addresses (similar to size_t
being used for sizes, etc.), uint32_t conveys less information -- only
the size.

It's obviously more informative, but I thought it's main purpose is to be used with code that could be executed for a different targets (with different address bus width).


It's a safe hack, but I don't see the rationale.

I don't consider this a hack, we are trying to emulate real hardware, and pxa lcd and dma controllers are intended to work with 32-bit bus. We should not have a possibility to use them with 64-bit targets.

If it's because VMSTATE_UINT32 requires that specific type than a less
ugly hack would be to make a pxa specific memory address type.


Introducing new type doesn't look pretty to me, maybe just rename variables to source_addr, dest_addr e.t.c?


--
Mitsyanko Igor
ASWG, Moscow R&D center, Samsung Electronics
email: address@hidden



reply via email to

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