Re: [edk2] [PATCH 1/2] i386/pc: propagate flash size from pc_system_flash_init() to pc_init1()

Subject: Re: [edk2] [PATCH 1/2] i386/pc: propagate flash size from pc_system_flash_init() to pc_init1()

From: Laszlo Ersek <>

To: Peter Maydell <>

Date: 2013-11-09 00:27:57

On 11/08/13 16:16, Peter Maydell wrote:
> On 8 November 2013 15:07, Laszlo Ersek  wrote:
>> On 11/08/13 07:09, Jordan Justen wrote:
>>> int64_t? :)
>> Heh, yes, I did cringe when I wrote that, but if you check the
>> bottom-most function, where the assignment happens,
>> pc_system_flash_init(), it declares the local "size" variable as
>> int64_t. I've given up on arguing for sensible unsigned types so I just
>> went with the flow
> That's a bug in that function which should be fixed.
> This is a memory region size and those are uint64_t.
> That said, having to pass the size of a sub-sub-region
> all the way back up the call stack is very odd and makes
> me wonder if it's really the right way to do it...
> The top level shouldn't have to care like that about
> details of the bottom of the callstack.

I agree. It's just that system.flash and pci-hole are siblings in the
same container (they shouldn't overlap, *or* they should have clearly
different priorities between them). We have two call chains rooted in
pc_init1(), and the "ends" of those chains need to coordinate with each
other (they set up the two regions, respectively, and both need the
boundary between them). We could introduce a new global, but that's not
exactly a step forward :)


November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
edk2-devel mailing list