On 06/28/2011 04:25 PM, Peter Maydell wrote:
On 28 June 2011 13:09, Avi Kivity<a...@redhat.com> wrote:
> Okay, let's make t_p_a_t max(bus size in system).
If you want a type for that, can't you give it a sensible (ie
different) name? target_phys_addr_t is pretty clearly "the type
of a physical address for this target" and having it actually
be something else is just going to be confusing.
"a physical address" is ambiguous. There are many physical addresses
flowing around. Certainly it's most natural to think about the
processor's physical address bus, but that's not always useful.
Since all *devices* use target_phys_addr_t, I think we should just adopt
that to avoid major and pointless churn.
> Do we have 32-bit targets
> that don't support pci (I guess, pc-isa with cpu< ppro?). Do we want to
> support a 32-bit variant of pci? It certainly existed at some point.
As a thought experiment, you could take an existing 32 bit
target and define a new board model that happens to have eg a
new pci controller on it. It doesn't seem right that that
should cause the system's idea of this type width to change,
it's just a new device model and board. So if you have this
type I think it ought to be max(bus size of widest bus qemu
supports).
That indicates
typedef uint64_t target_phys_addr_t;
--
error compiling committee.c: too many arguments to function