On Sun, Nov 7, 2010 at 1:46 PM, Andreas Färber andreas.faerber@web.de wrote:
Am 07.11.2010 um 14:30 schrieb Mark Cave-Ayland:
Andreas Färber wrote:
Ah good spot - would FMT_phys_addr_t be a suitable name for this? I'll make the defaults for SPARC64 and PPC the same as those for ucell.
Judging by include/arch/ppc/types.h I'd prefer FMT_physaddrt (without the trailing _t that makes it look like a type itself). QEMU has TARGET_FMT_plx, so we might use FMT_plx (physical long hexadecimal?).
(Looks like our previous emails have crossed)
Yeah, again!
I can see the argument for renaming the FMT argument to avoid confusion with proper types, but
introducing TARGET_FMT_plx seems a little excessive.
That's why I suggested FMT_plx without the TARGET_ prefix...
I'd agree. Otherwise the patch seems to be OK.
I'm merely sticking with the existing OpenBIOS convention rather than attempting to change it within the scope of this patch :)
...and it's not a change but a new definition. Blue was asking for name reuse from QEMU when I introduced the type, and Alex was recently asking for name reuse from Linux. Don't know about the latter.
Would be nice to have their introduction in a separate, preceding patch.
I really can't get too excited about this as I don't see what benefit it would have over a single commit to implement the type change in this case.
Logically, it is simply an addition to my r932 and has nothing to do with ofmem.
Practically, if something breaks during/after the ofmem migration it is better for bisecting and possible reverting with tools like git-revert to leave separate things separate.
I'd be volunteering to supply a patch, after all I'm to blame for introducing phys_addr_t. ;)
Great!