genode

History

Norman Feske 17c79a9e23 base: avoid use of deprecated base/printf.h Besides adapting the components to the use of base/log.h, the patch cleans up a few base headers, i.e., it removes unused includes from root/component.h, specifically base/heap.h and ram_session/ram_session.h. Hence, components that relied on the implicit inclusion of those headers have to manually include those headers now. While adjusting the log messages, I repeatedly stumbled over the problem that printing char * arguments is ambiguous. It is unclear whether to print the argument as pointer or null-terminated string. To overcome this problem, the patch introduces a new type 'Cstring' that allows the caller to express that the argument should be handled as null-terminated string. As a nice side effect, with this type in place, the optional len argument of the 'String' class could be removed. Instead of supplying a pair of (char const , size_t), the constructor accepts a 'Cstring'. This, in turn, clears the way let the 'String' constructor use the new output mechanism to assemble a string from multiple arguments (and thereby getting rid of snprintf within Genode in the near future). To enforce the explicit resolution of the char ambiguity, the 'char *' overload of the 'print' function is marked as deleted. Issue #1987		2016-08-29 17:27:10 +02:00
..
input_rom_registry.h	base: avoid use of deprecated base/printf.h	2016-08-29 17:27:10 +02:00
main.cc	base: avoid use of deprecated base/printf.h	2016-08-29 17:27:10 +02:00
README	rom filter: amend name of run script in README	2015-12-17 10:38:19 +01:00
target.mk	os: new ROM filter component	2015-10-06 12:18:53 +02:00

README

The ROM filter provides a ROM module that depends on the content
of other ROM modules. Its designated use is the dynamic switching between
configuration variants dependent on the state of the system. For example,
the configuration of the window decorator may be toggled depending on whether
nitpicker's X-ray mode is active or not.


Configuration
~~~~~~~~~~~~~

The configuration consists of two parts. The first part is the declaration of
input values that are taken into the account. The input values are obtained
from ROM modules that contain XML-formatted data. Each input value is
represented by an '<input>' node with a unique 'name' attribute. The 'rom'
attribute specifies the ROM module to take the input from. If not specified,
the 'name' is used as the ROM name. The type of the top-level XML node can be
specified via the 'node' attribute. If not present, the top-level XML node is
expected to correspond to the 'name' attribute.

The second part of the configuration defines the output via an '<output>' node.
The type of the top-level XML node must be specified via the 'node' attribute.
The '<output>' node can contain the following sub nodes:

:'<inline>':
  Contains content to be written to the output.

:'<if>':
  Produces output depending on a condition (see below). If the condition
  is satisfied, the '<then>' sub node is evaluated. Otherwise, the '<else>'
  sub node is evaluated. Each of those sub nodes can contain the same
  nodes as the '<output>' node.


Conditions
----------

The '<has_value>' condition compares an input value (specified as 'input'
attribute) with a predefined value (specified as 'value' attribute). The
condition is satisfied if both values are equal.


Example
~~~~~~~

For an example that illustrates the use of the component, please refer to the
_os/run/rom_filter.run_ script.