The original loader service was primarily motivated by the
browser-plugin scenario presented on our live CD. The new version
implements a more general session interface, which widens the
application scope of the service and, at the same time, reduces its
implementation complexity.
The complexity reduction is achieved by removing the original limitation
of supplying the new sub system as a single binary blob only. The server
used to implement heuristics and functionality for dealing with
different kinds of blobs such as ELF images or TAR archives. This has
been replaced by a session-local ROM service, which can be equipped with
an arbitrary number of ROM modules supplied by the loader client prior
starting the new sub system. Even though the TAR support has been
removed, a separate instance of the 'tar_rom' service can be used within
the subsystem to provide the formerly built-in functionality.
If any operand of the '?' operator is of an unsigned type, the result
is unsigned by default. Thanks to Julian Stecklina for finding
this out.
Fixes#189.
This patch allows to configure the amount of RAM that GDB monitor should
preserve for itself. The configuration syntax looks as follows:
<start name="gdb_monitor">
<resource name="RAM" quantum="1G"/>
<config>
<target name="noux">
<preserve name="RAM" quantum="2M"/>
...
</config>
</start>
Fixes#190.
The new 'chroot' tool at 'os/src/app/chroot' allows for executing
subsystems within chroot jails on Linux. For using the tool, please
refer to the test case 'os/run/chroot.run'. Fixes#37
This patch enables the use of threads and locking mechanisms in SDL
applications. The 'pthread' libary is used as backend. Not all features
are currently supported.
Fixes#185.
With this patch clients of the RM service can state if they want a mapping
to be executable or not. This allows dataspaces to be mapped as
non-executable on Linux by default and as executable only if needed.
Partially fixes#176.
This patch reads program arguments from the config file and makes them
available to the application via the 'argc' and 'argv' arguments of the
'main()' function. The configuration syntax looks like this:
<config>
<arg value="...">
<arg value="...">
...
</config>
The 'value' attribute of the first <arg> node becomes 'argv[0]' and so on.
Fixes#184.
With this patch GDB monitor provides a 'config' file to the target. Its
content can be defined in the <config> sub node of the <target> XML node.
Fixes#179.
This patch introduces support for ROM sessions that update their
provided data during the lifetime of the session. The 'Rom_session'
interface had been extended with the new 'release()' and 'sigh()'
functions, which are needed to support the new protocol. All ROM
services have been updated to the new interface.
Furthermore, the patch changes the child policy of init
with regard to the handling of configuration files. The 'Init::Child'
used to always provide the ROM dataspace with the child's config file
via a locally implemented ROM service. However, for dynamic ROM
sessions, we need to establish a session to the real supplier of the ROM
data. This is achieved by using a new 'Child_policy_redirect_rom_file'
policy to handle the 'configfile' rather than handling the 'configfile'
case entirely within 'Child_config'.
To see the new facility in action, the new 'os/run/dynamic_config.run'
script provides a simple scenario. The config file of the test program
is provided by a service, which generates and updates the config data
at regular intervals.
In addition, new support has been added to let slaves use dynamic
reconfiguration. By using the new 'Child_policy_dynamic_rom_file', the
configuration of a slave can be changed dynamically at runtime via the
new 'configure()' function.
The config is provided as plain null-terminated string (instead of a
dataspace capability) because we need to buffer the config data anyway.
So there is no benefit of using a dataspace. For buffering configuration
data, a 'Ram_session' must be supplied. If no 'Ram_session' is specified
at construction time of a 'Slave_policy', no config is supplied to the
slave (which is still a common case).
An example for dynamically reconfiguring a slave is provided by
'os/run/dynamic_config_slave.run'.
The new 'swap' and 'realloc' functions are needed in scenarios where
'Attached_ram_dataspace' is used to implement double buffering. The
particular use case is the implementation of dynamic ROM sessions.
When the pager gets a pagefault, exception, pause, or wakeup request it's
always possible, that the corresponding thread gets destroyed between
receiving the message and looking up the thread's pager_object. This commit
unifies the check for a valid pager_object for each kind of requests to the
pager, thereby adds currently missing checks.
The build system overlays multiple source trees (repositories) such that
they can shadow libraries and include search paths. This patch extends
the shadowing concept to build targets. Furthermore, it streamlines the
build stage for generating library depenencies, reducing the processing
time of this stage by 10-20 percent. Fixes#165.
The 'copy_to' function turned out to be not flexible enough to
accommodate the Noux fork mechanism. This patch removes the function,
adds an accessor for the capability destination and a compound type
'Native_capability::Raw' to be used wherever plain capability
information must be communicated.
In applications that use ldso the main_thread_bootstrap() function is called
twice which results in the main thread's gate-capability to be inserted twice
in the Capability_map which results in an exception. Unfortunately at least
on ARM this exception cannot be handled that early, so this commit prevents
the exception by checking, whether the capability is inserted already or not.
Fixes#164.
When constructing a thread object its capability is inserted into the
capability map. Normally this is done by the ipc-unmarshalling code, but
in this case the thread-capability isn't transfered via normal IPC, but in
a special form via the thread_state object. In contrast to the unmarshalling
code, the thread-startup code doesn't check, whether the capability-map
already contains a deprecated entry with the same capability id before
inserting the thread's capability. This commit add the necessary check.
Moreover, a check is added to the insertion methods of the capability-map
to verify that capability-allocation didn't failed.
Removing a Cap_index from Capability_map in core can happen twice, via
Cap_session_component or destructor of a Cap_mapping. That it's checked
whether the index is part of the map before removing it. This patch puts
the check into the remove method, so both operations are within the same
lock context, to remove a race condition.
This is a follow up fix for commit d287b9d893
By commit d287b9d893 the Native_capability
class changed fundamentally in the Fiasco.OC platform code of Genode. Thereby
the cap_integrity test got incompatible with it. This commit introduces a
separate test implementation for Fiasco.OC that does semantically the same
like the old test. Please refer to issue #161.
By using the `compare_output_to` method from the run tool instead of using
regexp in the cap_integrity run-script, the test outputs the undesired lines
instead of just signaling that the test failed.
In the compare_output_to function in the run tool a check was introduced,
whether the given arguments are empty, and if so if the output string is it
too. Without this patch compare_output_to succeeded when the given pattern
was empty but output wasn't. Please refer to issue #162.
This commit introduces a Cap_index class for Fiasco.OC's capabilities.
A Cap_index is a combination of the global capability id, that is used by Genode
to correctly identify a kernel-object, and a corresponding entry in a
protection-domain's (kernel-)capability-space. The cap-indices are non-copyable,
unique objects, that are held in a Cap_map. The Cap_map is used to re-find
capabilities already present in the protection-domain, when a capability is
received via IPC. The retrieval of capabilities effectively fixes issue #112,
meaning the waste of capability-space entries.
Because Cap_index objects are non-copyable (their address indicates the position
in the capability-space of the pd), they are inappropriate to use as
Native_capability. Therefore, Native_capability is implemented as a reference
to Cap_index objects. This design seems to be a good pre-condition to implement
smart-pointers for entries in the capability-space, and thereby closing existing
leaks (please refer to issue #32).
Cap_index, Cap_map, and the allocator for Cap_index objects are designed in a way,
that it should be relatively easy to apply the same concept to NOVA also. By now,
these classes are located in the `base-foc` repository, but they intentionally
contain no Fiasco.OC specific elements.
The previously explained changes had extensive impact on the whole Fiasco.OC
platform implementation, due to various dependencies. The following things had to
be changed:
* The Thread object's startup and destruction routine is re-arranged, to
enable another thread (that calls the Thread destructor) gaining the
capability id of the thread's gate to remove it from the Cap_map, the
thread's UTCB had to be made available to the caller, because there
is the current location of that id. After having the UTCB available
in the Thread object for that reason, the whole thread bootstrapping
could be simplified.
* In the course of changing the Native_capability's semantic, a new Cap_mapping
class was introduced in core, that facilitates the establishment and
destruction of capability mappings between core and it's client's, especially
mappings related to Platform_thread and Platform_task, that are relevant to
task and thread creation and destruction. Thereby, the destruction of
threads had to be reworked, which effectively removed a bug (issue #149)
where some threads weren't destroyed properly.
* In the quick fix for issue #112, something similar to the Cap_map was
introduced available in all processes. Moreover, some kind of a capability
map already existed in core, to handle cap-session request properly. The
introduction of the Cap_map unified both structures, so that the
cap-session component code in core had to be reworked too.
* The platform initialization code had to be changed sligthly due to the
changes in Native_capability
* The vcpu initialization in the L4Linux support library had to be adapted
according to the already mentioned changes in the Thread object's bootstrap
code.
