Re: [Qemu-devel] RFC: memory API changes

[Peter Maydell]

On 24 March 2015 at 20:00, Paolo Bonzini <address@hidden> wrote:
> On 24/03/2015 19:06, Peter Maydell wrote:
>> I think this is where we disagree. I see ld/st*_phys as being
>> really generic -- they take an AddressSpace, after all, and
>> part of the same family with address_space_read &c. If you
>> don't leave them as generic, then you end up having to use
>> the really awkward _read/_write for simple accesses and
>> then manage the byteswapping yourself. That's why I want
>> to rename them into address_space_* : to indicate that they
>> are all part of the same family, and you can use
>> address_space_read if you want to read an arbitrary byte
>> buffer, or address_space_ldl_be if you want to read a
>> big endian 32 bit word, and so on.
>
> I agree with that.  I just want to keep ld/st*_phys _in addition_ as the
> short forms of address_space_ld/st*, and keep ld/st*_phys instead of
> address_space_ld/st* for those uses that have cs->as as the first argument.

...but for ARM I want to be able to specify the memory
attribute argument (and possibly also get the behaviour
right on failure). So I definitely don't want the short
forms for my cs->as uses. And it seems to me at best
uncertain that anybody does, in the long run. So why leave
temptingly short and simple looking function names in
the codebase to trip people up?

> The rationale is to evolve ld/st*_phys into CPU-specific accessors
> paralleling the bus-specific accessors.

I don't think this is any harder starting from
address_space_ld/st* than if we leave ld/st*_phys
around.

-- PMM