On Tuesday 01 November 2011 14:37:24 Matthias Weisser wrote:
I don't know the memory layout strategies for all the Linux/Unix variant out there. But typically text/bss/data is in the lower address range (some megs above 0) and in the upper range (right under kernel space) there is space used for stack and shared objects. Even with ASLR the address I used in the patch should be mappable.
relying on any address layout behavior is doomed to fail. and in this case, it's unnecessary. so let's not bother.
also, with Simon's other patch to md to use the remap func, the address of our memory backing store doesn't matter.
Well, you are right. But with the posted patch you don't need any remap function and md/mm/mtest/mw works out of the box.
This is interesting. What is the test purpose of specifying a particular virtual address for your memory?
Emulating the behavior of a u-boot on real hardware as close as possible. We have some chunk of memory at a given location. Thats it. With a minimum of additional work we can also simulate additional banks of RAM using multiple mmaps.
adding a CONFIG knob to control the virtual address of the memory is fine
If this is useful then we should make the mmap function fail if it cannot honour the address, since otherwise presumably some tests will fail.
Maybe. But on the other hand tests can always extract the actual address of RAM from gd->bd->bi_dram[0].start. If test use these address we can abandon the use of of fixed address. But I still thinks its nice to have an aligned address of RAM start as this is what we have on (all?) real hardware.
i'd rather see bi_dram die than extend it. if you want to utilize the virtual memory, let's use the already existing map helper. -mike