On 25 March 2015 at 11:34, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > On 25/03/2015 00:41, Peter Maydell wrote: >> On 24 March 2015 at 20:00, Paolo Bonzini <pbonz...@redhat.com> 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
