MMU support questions
tobias.schoofs at gmx.net
Mon Mar 28 20:25:09 UTC 2011
Is it wise to protect memory on a per-task basis? This would lead to a
concept of heavy task where each context-switch includes an address
I would imagine memory protection to separate different "applications"
or "components" from each other (without detailing here, how this
entities are defined in detail - that is a matter of "policy", whereas
MMU support is a "mechanism" that may be used to implement a policy).
The idea would be to have containers that define memory resources and
threads that belong to these containers. The containers may be defined
at design time, so that there is no direct coupling of MMU support and
In this scheme, a container is something similar to what is called
"process" in AADL; one could also refer to POSIX where processes contain
threads. I would like not to emphasise the reference to POSIX too much,
to avoid connotations with other concepts of POSIX processes that are
not necessarily related to MMU support. Instead, I would still refer to
tasks as the scheduling unit and to "processes" in terms of memory
containers with tasks. An address space switch from one process to the
other occurs whenever a task becomes active that is in another process
then the previously running task. So, with a good design of task
scheduling, one can partition the system into periods of different
processes - resembling an ARINC 653 paritioning scheme, but without the
rigidness of such a system and without the need to add a partitioning
On 03/28/2011 04:50 PM, Peter Dufault wrote:
> On Mar 28, 2011, at 11:13 , quanming shi wrote:
>> what will be the main use of the MMU Support API ? OS like MinixPPC allow load module dynamicly, and the need to protect the page memory allocated to the process. But RTEMS don't support dynamic load function.
> Many of us load the process into memory over the network using a boot loader. Protecting the code after loading is applicable in that situation as well. You'll need to pay attention to dynamically generated wrappers, etc, that may be used on some architectures.
> Other items I'd like to see related to MMU support are:
> - Unmapping the zero page to trap NULL pointer dereferences;
> - Having an option for stacks that are private per task. This means shared objects can't live on the stack, but I've worked on such systems and don't consider it a show-stopper;
> - Making private heap regions that are only activated when a task is activated. Again, obviously shared objects can't live in those regions.
> Peter Dufault
> HD Associates, Inc. Software and System Engineering
> rtems-users mailing list
> rtems-users at rtems.org
More information about the users