Talk:MMU Support
From RTEMSWiki
Here are some thoughts about the details of the MMU support implementation.
Contents |
Functionality to be implemented
For me it is still a bit unclear, what the MMU Support shall actually achive from an application perspective. A list of goals could be:
- allow tasks to create "private" memory regions, which are only accessible for that task
- allow the kernel to write-protect the code areas
- allow the kernel to protect the kernel data structures located in the workspace
- define access attributes (like: cache-inhibit, read-only,...) for certain memory regions
Terms to be used
We need fixed terms to give things a unique name, this avoid confusion in the function names and documentation.
- the minimum chunk of memory that can be handled independent in the MMU (e.g. 4kByte on PPC)
- a group of chunks that are located close to each other and shared the access attributes
- a group of access attributes
High-level API
A high-level API (architecture-independent) to make the MMU usable for tasks and the kernel would have the following requirements:
- define a context for each task, the kernel and maybe for interrupts
- maintain memory region lists for each context
- define functions to add/remove/modify regions to a certain context
- define functions to clear all regions of a context (e.g. when a task is deleted)
- define functions to activate/deactivate a certain context
- maybe allow, that multiple contexts are active at the same time, e.g. when a kernel function is executed from a certain task, it may be useful to allow access to the current task private memory and also to the kernel/workspace area.
- contain functions to allow the low-level MMU functions to query information about a certain memory region in the current context
Note: this API is not necessarily part of the current GSoC project, but should be kept in mind when doing the lower level stuff
High-Level API Data Structures
We need data structures for:
- a memory context
- a memory context entry (defining a memory region)
...
High-Level API Functions
Low-level API
A low-level MMU API should map the context information (and its changes) to the actual MMU hardware: the registers, the page-table entries and other data structures. It should be general enough, that it can be implemented for various architectures (e.g. PowerPC, i386, ARM, Coldfire).
...
