MMU support questions

[Tobias Schoofs]

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 
space switch.

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 
dynamic loading.

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 
kernel.

Tobias

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
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>