On loading userspace data into particular section of physical memory (ARM)

[Joel A Fernandes]

On Tue, Dec 4, 2012 at 11:19 PM, Subramaniam Appadodharana
<c.a.subramaniam at gmail.com> wrote:
> Hi,
>
>
> On Tue, Dec 4, 2012 at 11:07 PM, Joel A Fernandes <agnel.joel at gmail.com>
> wrote:
>>
>> I am looking at a problem that might be too difficult to solve, or
>> might not if I'm missing something so I thought I'd bounce it off this
>> group,
>>
>> Basically I have an application in userspace who's ".data" section
>> _has_ to be loaded into particular locations in physical memory. That
>> is, there is a chunk of physical memory that has to contain the .data
>> section and no other part of physical memory should.
>
> This is something unconventional. I wouldn't expect user space to mandate
> that.  I think you are approaching the problem in a wrong way.

It is unconventional of course.

>> What is the easiest way to do this? I guess, changes might be required
>> to the ELF loaders in fs/bin*.c. Any other tricks?
>>
> Why would you want to do that? Even if you do that, how are you going to
> achieve this for just your application. What even you change here (even if
> that the right place to do it), would be applicable for all processes. I
> dont think you want that, do you?

No, just for this process if we could use any directives that could
mark the section in a certain way.

>> Is it non-trivial to add a new memory zone to the kernel that manages
>> a particular section of physical memory? I thought if a new zone could
>> be added, then we could possibly modify the kernel ELF loader to
>> recognize a specially marked .data section and alloc memory from that
>> special zone when allocating page frames.
>>
>> Let me know if you have any ideas, Thanks,
>>
>
> I am not sure why you would need data section to be in a certain physical
> memory, but if all you want is to copy a certain data from userspace to be
> shared with a peripheral or some thing that could be done.
> One way to do it would be to have a driver (you own memory manager if you
> will) that would reserve this physical memory during bootup, and then can
> have a char device interface that you would call from your user app to
> request for memory.

No, that would require modifications to the userspace code itself
which doesn't work as there is lots of code that needs to be changed.
What would be an ideal solution is if the whole physical memory
allocation transparent to the user process involved.

> Would be interesting to see your use case!

The use case is one of- separating the code and data section into
different physical memory areas. Currently, kernel allocates pages for
user code and data mixed interspersed across physical memory (without
caring about whether its code or data).
This works fine, but incurs a very high performance hit for a certain
application.