On 11/08/13 16:16, Peter Maydell wrote: > On 8 November 2013 15:07, Laszlo Ersek <ler...@redhat.com> 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 :) Thanks Laszlo
