qemu-devel
[Top][All Lists]
Advanced

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

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


From: Peter Maydell
Subject: Re: [Qemu-devel] RFC: memory API changes
Date: Wed, 25 Mar 2015 11:43:03 +0000

On 25 March 2015 at 11:34, Paolo Bonzini <address@hidden> wrote:
>
>
> On 25/03/2015 00:41, Peter Maydell wrote:
>> On 24 March 2015 at 20:00, Paolo Bonzini <address@hidden> wrote:
>>> 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.
>
> You're free to move ARM to the longer versions, and/or to push the short
> versions to all cpu.h files except ARM's.
>
>> And it seems to me at best
>> uncertain that anybody does, in the long run.
>
> I disagree: most CPUs are in odd fixes/unmaintained state (so attributes
> probably won't matter), and most don't even define an unassigned_access
> callback (so result won't matter either).

I was trying to avoid leaving us with yet another half-finished
set of API transitions: because many of our CPUs are in this
odd-fixes state, it's unlikely anybody will get round to
updating them in the near future, so we'll be carrying a
duplicate set of functions around for a long time. Doing
an automated update to change everything to the new style
seemed a better plan to me.

If you insist I can leave the ldl_phys&c around as wrappers
with a comment saying /* Do not use these in new code;
use address_space_* instead. */,
though.

-- PMM



reply via email to

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