On 06/28/2011 04:25 PM, Peter Maydell wrote:
On 28 June 2011 13:09, Avi Kivity<avi@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
