A Fluke mapping object makes a region's memory accessible in a task at a selected address. Mapping objects are the mechanism by which tasks populate their own or other task's address spaces. Given a region reference object, a task may map all or part of the region at a given address with specified access permissions.
The actual access allowed to a mapped region of memory depends not only on the permission associated with the mapping object itself but also on the permissions of the region object from which the mapping is derived (and recursively, on the permissions of all ``higher level'' region objects). The permissions associated with a mapping object itself may or may not effect regions or other mappings derived from it depending on the Fluke implementation. For implementations where the permissions only apply to the associated task, region objects derived from a mapping are not further constrained by the permissions of the mapping, only by the permissions of the region from which the mapping was formed. The rationale for this optional feature was so that POSIX mprotect could be implemented as efficiently as possible. For example, toggling the permission of a mapping between read-write and read-only would otherwise require searching the mapping hierarchy for derived mappings and flushing any hardware context (e.g., TLB entries) for them.
Any fault caused by a thread accessing memory covered by a mapping which disallows the indicated access, results in a synchronous exception to the thread itself (if exceptions are enabled) or a synchronous idempotent IPC to the thread's ``task keeper'' (if disabled). A fault caused by higher level permission restrictions results in a synchronous exception IPC to the appropriate ``region keeper.''
The portion of a task's address space that can be ``mapped'' is architecture dependent. For example, some parts of a task's address space may be reserved for kernel uses such as the Fluke entry point area.