In scenarios where the config ROM is loaded from a report ROM or any
other non-static ROM, config might try to access an invalid dataspace
capability. This patch prevents the component from aborting in this
case.
Fixes#1914
This commit replaces the stateful 'Ipc_client' type with the plain
function 'ipc_call' that takes all the needed state as arguments.
The stateful 'Ipc_server' class is retained but it moved from the public
API to the internal ipc_server.h header. The kernel-specific
implementations were cleaned up and simplified. E.g., the 'wait'
function does no longer exist. The badge and exception code are no
longer carried in the message buffers but are handled in kernel-specific
ways.
Issue #610
Issue #1832
If ports need preparation in order to execute a run script, use the
knowledge about the actual genode directory to suggest a command to the
user that can be directly copied to the command line.
Rust relies on atomic builtins, which are not implemented in libgcc for
ARM. One is implemented in rust, which is sufficient to get the
current rust test to run.
Issue #1899
Check if the binary pointer is valid before attempting to lookup the
symbol. Shared objects with unresolved symbols and missing depencies,
e.g a library that references 'errno' but is not linked against libc,
will now produce an error message when they are loaded by the dynamic
linker.
Fixes#1904.
This patch moves details about the stack allocation and organization
the base-internal headers. Thereby, I replaced the notion of "thread
contexts" by "stacks" as this term is much more intuitive. The fact that
we place thread-specific information at the bottom of the stack is not
worth introducing new terminology.
Issue #1832
The interfaces linux_cpu_session, local_capability, linux_dataspace,
linux_native_pd are mere implementation necessities. They are meant for the
internal use by the framework only. So it is appropriate to move them to
base/internal/.
Issue #1832
On seL4 and L4/Fiasco, we employ a simple yielding spinlock as lock
implementation. Consequently these base platforms used to have a
simplified header. However, since the regular cancelable_lock has all
the member variables needed to implement a spinlock, we can simply use
the generic header on those two platforms too, just leaving some other
parts of the generic header unused. So at API level, the difference is
not visible.
Issue #1832
By moving the stub implementation to rm_session_client.cc, we can use
the generic base/include/rm_session/client.h for base-linux and
base-nova and merely use platform-specific implementations.
Issue #1832
This patch establishes a common organization of header files
internal to the base framework. The internal headers are located at
'<repository>/src/include/base/internal/'. This structure has been
choosen to make the nature of those headers immediately clear when
included:
#include <base/internal/lock_helper.h>
Issue #1832
This patch integrates the functionality of the former CAP session into
the PD session and unifies the approch of supplementing the generic PD
session with kernel-specific functionality. The latter is achieved by
the new 'Native_pd' interface. The kernel-specific interface can be
obtained via the Pd_session::native_pd accessor function. The
kernel-specific interfaces are named Nova_native_pd, Foc_native_pd, and
Linux_native_pd.
The latter change allowed for to deduplication of the
pd_session_component code among the various base platforms.
To retain API compatibility, we keep the 'Cap_session' and
'Cap_connection' around. But those classes have become mere wrappers
around the PD session interface.
Issue #1841
This patch removes the SIGNAL service from core and moves its
functionality to the PD session. Furthermore, it unifies the PD service
implementation and terminology across the various base platforms.
Issue #1841
This patch removes the support for executing subsystems of CLI monitor
within the GDB monitor. There are multiple reasons: First, the feature
remained unused for multiple years. Second, it relied on the base/elf.h
header to determine whether the started binary is dynamically or
statically linked. This header, however, is going to be removed from the
Genode API. Third, the feature will eventually break with the upcoming
changes of how components are bootstrapped. Finally, there is the plan
to turn CLI monitor into a sole front end of a dynamically configurable
init component. Once we pursue this plan, we'd need to reconsider the
GDB support anyway.
Issue #1832
The commit avoids the need to have contrib sources of the kernel
available for this run script. We actually just want to build core and
not the kernel itself, which is always required after recent changes in
the ports tool.
This is the default optimization level in the original seL4 SDK. By
adapting to O3, we work around a bug [1] in version 2.1.0 that only
shows on low optimization levels.
[1] https://github.com/seL4/seL4/issues/20
Previously, ports that were needed for a scenario and that were not
prepared or outdated, triggered one assertion each during the second
build stage. The commit slots a mechanism in ahead that gathers all
these ports during the first build stage and reports them in form of a
list before the second build stage is entered. This list can be used
directly as argument for tool/ports/prepare_port to prepare respectively
update the ports. If, however, this mechanism is not available, for
example because a target is build without the first build stage, the old
assertion still prevents the target from running into troubles with a
missing port.
Fixes#1872
To raise readability when preparing multiple ports in parallel we prefix
also the git clone output with the port name dark-yellow-coloured. To
achieve this we sed the git output. In sed \x1b[ resolves to an escape
sequence and \033[, that we use normally, doesn't. The echo command, at
the other hand, resolves both to an escape sequence. Thus we use the
sed-compatible version in general. This commit inhibits the progress
output of git clone as it can't be redirected to sed.
Ref #1872
The tool/prepare_port tool is now able to handle a list of ports that
shall be prepared. Additionally, one may state the number of ports that
shall be prepared in parallel at a max by using the -j parameter. If -j
is not set by the user, the tool acts as with -j1. The previous
implementation of the tool that prepares only a single port was moved to
tool/ports/mk/prepare_single_port.mk and acts as back end to the new
prepare_port tool. The interface of the new prepare_port tool is
backwards compatible. When called for one port only, the behavior is the
same as when calling tool/ports/mk/prepare_single_port.mk directly.
Removes "usage" rule from prepare_single_port.mk. Removes shebang line
from prepare_single_port.mk.
Ref #1872