[GSoC] Defining regions of memory to apply attributes on it

[Gedare Bloom]

On Fri, Jul 12, 2013 at 3:57 PM, Hesham Moustafa
<heshamelmatary at gmail.com> wrote:
> Hi,
>
> The current test cases for libmm use hard-coded memory region addresses to
> apply memory attributes on. We want to remove that BSP dependency and hide
> any target specs to enable test cases to run for any BSP. I would suggest
> some solutions for your review :
>
> - Use the current allocators like partition/region managers.
This should be possible. I think at least one of them was initially
designed to support MMU protection in either the ORKID or RTEID
standards. I can hunt down the document that describes it. We
converted the design documents during last GCI (code-in).

> - Define an area of memory in linkcmds that acts as a pool for libmm to
> dynamically allocate and apply attributes for.
It does not make sense to carve out part of the memory address space
just for the libmm use.

> - Use the free/busy list (stable enough ?)
It's not ready yet, but it would be a good way to manage the memory by
providing page-sized "buffers". What you would end up with is
something very similar to a slab allocator.

>
> Would it make sense to enable the user to specify hard-coded addresses (that
> are not within heap or workspace) in the application code ?
>
Yes.

Other ideas that might make sense would include mapping a relationship
between names and memory regions. Perhaps with a filesystem to specify
the names, and nodes (files) that define the memory region and
attributes.

> Regards,
> Hesham
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>