Memory Protection (Attributes)

[Thomas Doerfler]

Gedare,

so you made me subscribe to that list ;-) . Discussing your API
recommendation here makes sense. Getting a proper memory protection
API makes even more sense, and there were several attempts to get that
functionality.

I will give you my feedback without a particular order.


1.) Just a minor: When I look at your page

http://gedare-csphd.blogspot.com/2011/12/rtems-memory-protection-api.html

I can see only part of the comments. The code window seems fixe width,
and not all of the code is visible. Maybe this is due to my private
browser settings.

2.) In structure rtems_memory_protection_region_descriptor I tripped
over the nama of the "bounds" member. I would expect this to be named
"size" or "length". Maybe this is de to my limited knowledge of
english ;-)

3.) The names used get very long. "memory_protection" is a rather long
word. Maybe abreviating it to "MP" would make sense? I am not really
sure about that...

4.) Your "memory_protection_region_descriptor" describes a memory
region. Maybe the same structure might be useful also in a
"non-protection" context. So I think a name "memory_region_descriptor"
would also match its use?

5.) The term "region" already has a different meaning in the RTEMS
context, you know the "Classic API" object type "Region". UPS, and
here we have a collision with my recommendation in topic 4.

My first comments are mainly about names, but proper names are
important to avoid confusion (in code and in the head).

6.) I did not yet understand the context the memory protection will be
bound to. Are the installed MPDs valid for all tasks, or is it
possible to have MPDs that are only valid while a certain task is
active? Are the MPDs bound to a distinct core in a SMP system or to
all cores?

I know you are at the start of the API definitions, but I think these
are questions to be discussed.

And I hope you will go on in this attempt, so don't get my partial
critics wrong. I think MP will be an important feature for realtime
systems in the future, so we need a proper, common, portable API in RTEMS.

wkr,

Thomas Doerfler.



Am 05.12.2011 20:02, schrieb Gedare Bloom:
> Hi, I am working to bring primitives for real-time memory
> protection to RTEMS, and as a first step I have designed a solution
> for setting/enforcing attributes on memory regions. The design is
> in three layers: a high-level API (cpukit) layer, a middle layer
> for CPU family support (libcpu), and a low-level layer for
> hardware-specific support (libcpu/libbsp).
> 
> I have written a description of the API layer [1] and would
> appreciate any feedback. I prefer to have the feedback given
> publicly to the rtems-devel mailing list thread [2] (or privately
> to me directly).
> 
> I will describe the other layers in the near future. -Gedare
> 
> [1]
> http://gedare-csphd.blogspot.com/2011/12/rtems-memory-protection-api.html
>
> 
[2] http://www.rtems.org/pipermail/rtems-devel/2011-December/000004.html
> _______________________________________________ rtems-users mailing
> list rtems-users at rtems.org 
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9