Parent-child interaction in detail

On a conceptual level, the session-creation procedure as described in Section Services and sessions appears as a synchronous interaction between the parent and its child components. The interaction serves three purposes. First, it is used to communicate information between different protection domains, in this case the parent, the client, and the server. Second, it implicitly dictates the flow of control between the involved parties because the caller blocks until the callee replies. Third, the interplay delegates authority (in particular authority to access the server's session object) between protection domains. The latter is realized with the kernel's ability to carry capabilities as IPC message payload.

Figure 1

Parent-child interplay during the creation of a new session. The dotted lines are asynchronous notifications, which have fire-and-forget semantics. A component that triggers a signal does not block.

On the surface, the interaction looks like a sequence of synchronous RPC calls. However, under the hood, the interplay between the parent and its children is based on a combination of asynchronous notifications from the parent to the children and synchronous RPC from the children to the parent. The protocol is designed such that the parent's liveliness remains independent from the behavior of its children, which must generally be regarded as untrusted from the parent's perspective. The sequence of creating a session is depicted in Figure 1. The following points are worth noting:

• Sessions are identified via IDs, which are plain numbers as opposed to capabilities. The IDs as seen by the client and server belong to different ID name spaces. IDs of sessions requested by the client are allocated by the client. IDs of sessions requested at the server are allocated by the parent.

• The parent does not issue RPC calls to any of its children.

• Each activation of the parent merely applies a state change of the session's meta data structures maintained at the parent, which capture the entire state of session requests.

• The information about pending session requests is communicated from the parent to the server via a ROM session. At startup, the server requests a ROM session for the ROM module "session_requests" from its parent. The parent implements this ROM session locally. Since ROM sessions support versions, the parent can post version updates of the "session_requests" ROM with the regular mechanisms already present in Genode.

• The parties involved can potentially run in parallel.