On 1 July 2013 20:03, Richard Henderson <r...@twiddle.net> wrote: > I would think hwaddr wouldn't be appropriate, since that's supposed to be > talking about physical addresses, and that's not the case here. The name (and > admittedly minimal documentation for) ram_addr_t sounds right, but it seems to > be sized wrong, so I don't know what it's actually supposed to be.
ram_addr_t is for indexes into guest RAM, ie into what you get by concatenating all the RAMBlocks together. (This is why it's uintptr_t sized -- you know you can't have more RAM total than will fit into the host's address space.) It usually isn't what you want. Feel free to suggest improvements to HACKING -- I tried to describe this in the bit that goes "ram_addr_t is a QEMU internal address space ..." but since I already knew what it did I probably failed to explain sufficiently. Returning to the point, what we're after here is "a type which will hold a guest virtual address but whose size doesn't depend on the target the way target_ulong does", right? My inclination is to suggest that we have a 'vaddr' typedef by analogy with 'hwaddr'; it seems like that might make code dealing with guest addresses a little more self documenting. I don't feel very strongly about it though so if people think it's pointless/will cause problems that's fine. thanks -- PMM
