Kernel::resume_thread was restricted to core when the targeted thread was in
another domain. Now there are two kernel calls, resume_local_thread and
resume_thread, where the former is never restricted and is provided via
public kernel/interface.h and the latter is always restricted to core and
is provided via core-local kernel/core_interface.h.
ref #1101
Kernel::pause_current_thread can be implemented much simpler and is not
restricted to core threads, in contrast to Kernel::pause_thread which
also benefits from the split and can be moved to core_interface.h.
ref #1101
If an RM fault ends up in any trouble, the faulter remains paused and
the pager activation continues with the next fault. Thus we can print
a warning instead of an error and safe execution time in release mode.
ref #1096
In most cases an error report is not necessary in the kernel as the problem
does not affect the kernel itself but the according user-land context. Thus
we can also do a warning that is not printed in release mode and hence safe
execution time.
ref #1096
Previously for determining wether boot-up succeeded or not, we looked
for a message that is switched off in release mode. Now the kernel
provides a reliable message as soon as initialization is done.
ref #1096
* Core_mem_allocator: implement Range_allocator interface
* Core_mem_allocator: allocate with page-granularity only
* Use slab allocators in core where meaningful (e.g. dataspace objects)
The processor scheduler can determine without much overhead wether
the currently scheduled client becomes out-dated due to the insertion
of another client. This can be used to safe inter-processor interrupts
when a remote insertion doesn't imply an update of the currently
scheduled client.
fix#1088
At least with the ARM generic interrupt controller, inter-processor interrupts
are edge triggered and banked for all source processors. Thus it might be
possible that such an interrupt gets triggered redundantly until the targeted
processor is able to grab the kernel lock. As we're only interested in making
a processor recognize accumulative updates to its scheduler, we can omit
further interrupts if there is one pending already at the targeted processor.
ref #1088
This is needed as soon as we do inter-processor interrupts to
inform a processor about a remote modification in its scheduling plan.
In this case we can not explicitely decide wether to reset timer
or not. Instead we must decide it according to the choices of the
scheduler before and after the modification.
ref #1088
