Since the timer and timeout handling is part of the base library (the
dynamic linker), it belongs to the base repository.
Besides moving the timer and its related infrastructure (alarm, timeout
libs, tests) to the base repository, this patch also moves the timer
from the 'drivers' subdirectory directly to 'src' and disamibuates the
timer's build locations for the various kernels. Otherwise the different
timer implementations could interfere with each other when using one
build directory with multiple kernels.
Note that this patch changes the include paths for the former os/timer,
os/alarm.h, os/duration.h, and os/timed_semaphore.h to base/.
Issue #3101
This patch removes the detection of statically linked executables from
the base framework. It thereby fixes the corner cases encountered with
Sculpt when obtaining the binaries of the runtime from the depot_rom
service that is hosted within the runtime.
Statically linked binaries and hybrid Linux/Genode (lx_hybrid) binaries
can still be started by relabeling the ROM-session route of "ld.lib.so"
to the binary name, pretending that the binary is the dynamic linker.
This can be achieved via init's label rewriting mechanism:
<route>
<service name="ROM" unscoped_label="ld.lib.so">
<parent label="test-platform"/> </service>
</route>
However, as this is quite cryptic and would need to be applied for all
lx_hybrid components, the patch adds a shortcut to init's configuration.
One can simply add the 'ld="no"' attribute to the <start> node of the
corresponding component:
<start name="test-platform" ld="no"/>
Fixes#2866
The init component used to create the CPU/RAM/PD/ROM sessions (the child
environment) for its children by issuing session requests to its parent,
which is typically core. This policy was hard-wired. This patch enables
the routing of the environment sessions of the children of init
according to the configured routing policy.
Because there is no hard-wired policy regarding the environment sessions
anymore, routes to respective services must be explicitly declared in
the init configuration. For this reason, the patch adjusts several run
scripts in this respect.
This patch removes the outdated '<if-args>' special handling of session
labels. The '<if-args>' feature will eventually be removed completely
(ref #2250)
Issue #2197
Issue #2215
Issue #2233
Issue #2250
This patch unconditionally applies the labeling of sessions and thereby
removes the most common use case of 'Child_policy::filter_session_args'.
Furthermore, the patch removes an ambiguity of the session labels of
sessions created by the parent of behalf of its child, e.g., the PD
session created as part of 'Child' now has the label "<child-name>"
whereas an unlabeled PD-session request originating from the child
has the label "<child-name> -> ". This way, the routing-policy of
'Child_policy::resolve_session_request' can differentiate both cases.
As a consequence, the stricter labeling must now be considered wherever
a precise label was specified as a key for a session route or a server-
side policy selection. The simplest way to adapt those cases is to use a
'label_prefix' instead of the 'label' attribute. Alternatively, the
'label' attribute may used by appending " -> " (note the whitespace).
Fixes#2171
This patch integrates three region maps into each PD session to
reduce the session overhead and to simplify the PD creation procedure.
Please refer to the issue cited below for an elaborative discussion.
Note the API change:
With this patch, the semantics of core's RM service have changed. Now,
the service is merely a tool for creating and destroying managed
dataspaces, which are rarely needed. Regular components no longer need a
RM session. For this reason, the corresponding argument for the
'Process' and 'Child' constructors has been removed.
The former interface of the 'Rm_session' is not named 'Region_map'. As a
minor refinement, the 'Fault_type' enum values are now part of the
'Region_map::State' struct.
Issue #1938
This patch changes the top-level directory layout as a preparatory
step for improving the tools for managing 3rd-party source codes.
The rationale is described in the issue referenced below.
Issue #1082
