 |
L4Re Operating System Framework
Interface and Usage Documentation
|
|
L4Re Operating System Framework
Interface and Usage Documentation
|
Virtual address-space management. More...
Collaboration diagram for Region map API:Data Structures | |
| class | L4Re::Rm |
| Region map. More... | |
Virtual address-space management.
A region map object implements two protocols. The first protocol is the kernel page-fault protocol, to resolve page faults for threads running in an L4 task. The second protocol is the region map protocol itself, which allows managing the virtual memory address space of an L4 task.
There are two basic concepts provided by the region map abstraction:
Note that regions may live outside of areas and that an area does not necessarily contain any region.
Areas can be reserved for special use or for attaching a dataspace at a later time. When attaching a dataspace, the user can instruct the region map to search for an appropriate range to attach to. Regions are skipped in this search since they already have dataspaces attached to them, and, depending on L4Re::Rm::F::In_area, areas are skipped because they are reserved. Amongst others, areas can be used to attach several dataspaces inside a certain range of addresses without interference from other threads.
When a region map receives a page fault IPC, the region map will check if the faulting virtual address lies in a region. If yes, it will answer the page fault IPC with a mapping from the backing dataspace. If not, an error is returned.
Depending on the system type, an attached dataspace might or might not be mapped eagerly. MMU-based systems resort to lazy mapping while systems without MMU do eager mappings by default. The L4Re::Rm::F::Eager_map and L4Re::Rm::F::No_eager_map flags can be used to force the respective behaviour, independent of the underlying system. In case both flags are given, the L4Re::Rm::F::No_eager_map flag wins.
1.9.8