On 07.06.2016 16:40, Patrick Rudolph wrote:
On 2016-06-06 09:58 PM, ron minnich wrote:
On Mon, Jun 6, 2016 at 12:52 PM Patrick Rudolph siro@das-labor.org wrote:
To summarize: The easy way is to use 2G. The preferred way would be to mimic mrc behaviour and reboot after finding the correct size.
I'm not sure it's "easy vs. preferred" so much as
- simple that has no known failure cases (yet).
- best that requires that we have another variable we have to store in
flash
At least to me, it's not as cut and dried as easy vs. preferred. The preferred way adds a lot of moving runtime parts, and we'll need to cover for the case that the stored variable gets damaged somehow. The easy way is a runtime constant, which I kind of like.
If the "easy" way always works, i.e. we never find a case where it causes a problem, then it seems superior to me.
ron
There's a known failure case. If someone puts in multiple PCI cards that uses more than 2GB of mmio it'll break again.
And what will happen if you need more than 3GiB MMIO space? more than 4GiB? ... you have to set a limit somewhere. And that can be confi- gurable, IMO (It doesn't have to be Kconfig. I'd actually like to see it in the devicetree).
Most users won't reach this limit, but I'm wondering if I'm reaching it anytime soon. I want to use 2 PEG cards and the onboard intel card, which will be a good test-system.
I've read this serveral times and wonder how a stored variable could get damaged ? There is a checksum to verify the mrc cache. How should anything go wrong ?
Well, the checksum could be correct even if the data was damaged. Also, what do you do when the checksum is wrong but you need more MMIO space than the default? Try again to write the variable? Boot without suffi- cient MMIO space? Don't boot at all?
In case something writes to the flash you might get unexpected behavior anyway, won't you ?
Yes, but making this more complex makes unexpected behavior more likely.
Nico