Nested configuration concept
Genode's configuration concept is based on the ROM session interface described in Section Read-only memory (ROM). In contrast to a file-system interface, the ROM session interface is extremely simple. The client of a ROM service specifies the requested ROM module by its name as known by the client. There is neither a way to query a list of available ROM modules, nor are ROM modules organized in a hierarchic name space.
The ROM session interface is implemented by core's ROM service to make boot modules available to other components. Those boot modules comprise the executable binaries of the init component as well as those of the components created by init. Furthermore, a ROM module called "config" contains the configuration of the init process in XML format. To obtain its configuration, init requests a ROM session for the ROM module "config" from its parent, which is core. Figure 1 shows an example of such a config ROM module.
The config ROM module uses XML as syntax, which supports the expression of arbitrary structural data while being simple to parse. I.e., Genode's XML parser comes in the form of a single header file with less than 400 lines of code. Init's configuration is contained within a single <config> node.
Each component started by init obtains its configuration by requesting a ROM module named "config" from its parent. Init responds to this request by handing out a locally-provided ROM session. Instead of handing out the "config" ROM module as obtained from core, it creates a new dataspace that solely contains the portion of init's config ROM module that refers to the respective child. Analogously to init's configuration, each child's configuration has the form of a single <config> node. This works recursively. From each component's perspective, including the init component, the mechanism for obtaining its configuration is identical – it obtains a ROM session for a ROM module named "config" from its parent. The parent interposes the ROM session request as described in Section Interposing individual services. Figure 2 shows the successive interposing of "config" ROM requests according to the example configuration given in Figure 1. At each level, the information structure within the <config> node can be different. Besides following the convention that a configuration has the form of a single <config> node, each component can introduce arbitrary custom tags and attributes.
Besides being simple, the use of the ROM session interface for supplying configuration information has the benefit of supporting dynamic configuration updates over the lifetime of the config ROM session. Section Read-only memory (ROM) describes the update protocol between client and server of a ROM session. This way, the configuration of long-living components can be dynamically changed.