If newlines are in the string send to the core log service, they don't get
the label properly appended before each output. The messages then look like
they are coming from core.
Fixes#1368
This has to be used during shared object creation and destruction because global
lists are manipulated. We cannot use the 'Elf_object::lock' here because there
may be jump-slot relocations during object initialization.
Fixes#1350
This wasn't necessary before because we built an l4 library for
Pistachio and linked it against each application. With the new linker,
we compile the required files from within Genode and create a syscall
library that is only linked to ldso. If a program uses system calls
directly, for example, DDE kit's spinlock implementation, the required
symbols must be made globally accessible.
Fixes#1306
In the init configuration one can configure the donation of CPU time via
'resource' tags that have the attribute 'name' set to "CPU" and the
attribute 'quantum' set to the percentage of CPU quota that init shall
donate. The pattern is the same as when donating RAM quota.
! <start name="test">
! <resource name="CPU" quantum="75"/>
! </start>
This would cause init to try donating 75% of its CPU quota to the child
"test". Init and core do not preserve CPU quota for their own
requirements by default as it is done with RAM quota.
The CPU quota that a process owns can be applied through the thread
constructor. The constructor has been enhanced by an argument that
indicates the percentage of the programs CPU quota that shall be granted
to the new thread. So 'Thread(33, "test")' would cause the backing CPU
session to try to grant 33% of the programs CPU quota to the thread
"test". By now, the CPU quota of a thread can't be altered after
construction. Constructing a thread with CPU quota 0 doesn't mean the
thread gets never scheduled but that the thread has no guaranty to receive
CPU time. Such threads have to live with excess CPU time.
Threads that already existed in the official repositories of Genode were
adapted in the way that they receive a quota of 0.
This commit also provides a run test 'cpu_quota' in base-hw (the only
kernel that applies the CPU-quota scheme currently). The test basically
runs three threads with different physical CPU quota. The threads simply
count for 30 seconds each and the test then checks wether the counter
values relate to the CPU-quota distribution.
fix#1275
Do not support the global construction from of objects from within a global
constructor of another object. This can happen if, for example, dlopen is called
from a global constructor. The construction will be post-boned until the current
constructor has finished.
The memory barrier prevents the compiler from changing the program order
of memory accesses in such a way that accesses to the guarded resource
get outside the guarded stage. As cmpxchg() defines the start of the
guarded stage it also represents an effective memory barrier.
On x86, the architecture ensures to not reorder writes with older reads,
writes to memory with other writes (except in cases that are not
relevant for our locks), or read/write instructions with I/O
instructions, locked instructions, and serializing instructions.
However on ARM, the architectural memory model allows not only that
memory accesses take local effect in another order as their program
order but also that different observers (components that can access
memory like data-busses, TLBs and branch predictors) observe these
effects each in another order. Thus, a correct program order isn't
sufficient for a correct observation order. An additional architectural
preservation of the memory barrier is needed to achieve this.
Fixes#692
The backend allocator for the slab is a sliced heap, which hands out
allocations with page-size granularity (4096 bytes). Therefore, the
slab-block size should also be about a multiple of the page size minus
some bytes of overhead.
Additional adjustments:
- The slab-block size and the default quota-upgrade amount for SIGNAL
sessions depends on the platform bit width now.
- The signal test also stresses the case of many managed context in one
session including creation and destruction of the used signal receiver
in repeated rounds.
So far, the lifetime-management utilities 'Weak_ptr' and 'Locked_ptr'
had been preserved for core-internal use only. However, the utilities
are handy for many use cases outside of core where object lifetimes
must be managed. So we promote them to the public API.
When a page fault cannot be resolved, the GDB monitor can get a hint about
which thread faulted by evaluating the thread state object returned by
'Cpu_session::state()'. Unfortunately, with the current implementation,
the signal which informs GDB monitor about the page fault is sent before
the thread state object of the faulted thread has been updated, so it
can happen that the faulted thread cannot be determined immediately
after receiving the signal.
With this commit, the thread state gets updated before the signal is sent.
At least on base-nova it can also happen that the thread state is not
accessible yet after receiving the page fault notification. For this
reason, GDB monitor needs to retry its query until the state is
accessible.
Fixes#1206.
On ARM it's relevant to not only distinguish between ordinary cached memory
and write-combined one, but also having non-cached memory too. To insert the
appropriated page table entries e.g.: in the base-hw kernel, we need to preserve
the information about the kind of memory from allocation until the pager
resolves a page fault. Therefore, this commit introduces a new Cache_attribute
type, and replaces the write_combined boolean with the new type where necessary.
On ARM, when machine instructions get written into the data cache
(for example by a JIT compiler), one needs to make sure that the
instructions get written out to memory and read from memory into
the instruction cache before they get executed. This functionality
is usually provided by a kernel syscall and this patch adds a generic
interface for Genode applications to use it.
Fixes#1153.
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
