[OpenBIOS] [RFC] Switch OFMEM to use phys_addr_t for physical addresses

[Blue Swirl]

On Sun, Nov 7, 2010 at 1:46 PM, Andreas Färber <andreas.faerber at 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!