Session interfaces of the base API

PD session interface

The protection-domain (PD) service (Section Protection domains (PD)) enables the creation of address spaces that are isolated from each other. Each PD session corresponds to a protection domain. Each PD session is equipped with three region maps, one representing the PD's virtual address space, one for the component's stack area, and one for the component's linker area designated for shared objects. Of those region maps, only the virtual address space is needed by application code directly. The stack area and linker area are used by the framework internally. The PD service is rarely needed by applications directly but it is internally.

The PD session also represents a resource partition with a budget of physical memory and capabilities. Within the bounds of its RAM budget, it allows the client to allocate physical memory in the form of dataspaces.

Analogously, within the bounds of its capability budget, capabilities can be allocated and associated with a local object or a signal handler. Such a capability can be passed to another protection domain via an RPC call whereby the receiving protection domain obtains the right to send messages to the associated object or to trigger the associated signal handler respectively. The capability-management operations are not used directly by components at the API level but are used indirectly via the RPC mechanism described in Section Remote procedure calls and the signalling API described in Section Signalling.



Attached RAM dataspace

The instantiation of an Attached_ram_dataspace object subsumes the tasks of allocating a dataspaces from the component's PD session and attaching the dataspace to the component's region map. Furthermore, the reverse operations are performed during the destruction of an Attached_ram_dataspace object.


ROM session interface

The ROM service (Section Read-only memory (ROM)) provides access to ROM modules, e.g., binary data loaded by the boot loader (core's ROM service described in Section Access to boot modules (ROM)). Each session refers to one ROM module. The module's data is provided to the client in the form of a dataspace (Section Dataspaces).




Attached ROM dataspace

By instantiating an Attached_rom_dataspace object, a ROM module is requested and made visible within the component's address space in a single step.

To accommodate the common use of a ROM session as provider of configuration data (Section Component configuration) or an XML-formatted data model in a publisher-subscriber scenario Publishing and subscribing, the Attached_rom_dataspace provides a convenient way to retrieve its content as an XML node via the xml method. The method always returns a valid Xml_node even in the event where the dataspace is invalid or contains no XML. In such cases, the returned XML node is <empty/>. This relieves the caller from handling exceptions that may occur during XML parsing.


RM session interface

The region-map (RM) service (Section Region-map management (RM)) allows for the manual creation of region maps that represent (portions of) virtual address spaces. Components can use this service to manage the virtual memory layout of so-called managed dataspaces manually. For example, it allows a dataspace provider to populate the content of dataspaces on demand, depending on the access patterns produced by the dataspace user.

Note that the RM service is not available on all base platforms. In particular, it is not supported on Linux.



CPU session interface

The CPU service (Section Processing-time allocation (CPU)) provides a facility for creating and managing threads. A CPU session corresponds to a CPU-time allocator, from which multiple threads can be allocated.




Once created, a thread is referred to via a thread capability. This capability allows for the destruction of the thread via the CPU session, and provides the Cpu_thread RPC interface to operate on the thread.


IO_MEM session interface

The IO_MEM service (Section Access to device resources (IO_MEM, IO_PORT, IRQ)) enables user-level device drivers to obtain memory-mapped device resources in the form of dataspaces. Each IO_MEM session corresponds to the reservation of a physical address range, for which a dataspace is provided to the client. The user-level device driver can make the device resource visible in its address space by attaching the dataspace to the region map of its own PD session.




Attached IO_MEM dataspace

An instance of an Attached_io_mem_dataspace represents a locally mapped memory-mapped I/O range.


IO_PORT session interface

On the x86 architecture, the IO_PORT service (Section Access to device resources (IO_MEM, IO_PORT, IRQ)) provides access to device I/O ports via an RPC interface. Each IO_PORT session corresponds to the access right to a port range.



IRQ session interface

The IRQ service (Section Access to device resources (IO_MEM, IO_PORT, IRQ)) enables user-level device drivers to serve device interrupts. Each IRQ session corresponds to an associated interrupt line.


LOG session interface

For low-level debugging, core provides a simple LOG service (Section Logging (LOG)), which enables clients to print textual messages. In the LOG output, each message is tagged with the label of the corresponding client.