2012-05-30 18:13:09 +00:00
|
|
|
/*
|
2013-11-14 16:29:34 +00:00
|
|
|
* \brief Interface between kernel and userland
|
2012-05-30 18:13:09 +00:00
|
|
|
* \author Martin stein
|
|
|
|
* \date 2011-11-30
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2017-02-20 12:23:52 +00:00
|
|
|
* Copyright (C) 2011-2017 Genode Labs GmbH
|
2012-05-30 18:13:09 +00:00
|
|
|
*
|
|
|
|
* This file is part of the Genode OS framework, which is distributed
|
2017-02-20 12:23:52 +00:00
|
|
|
* under the terms of the GNU Affero General Public License version 3.
|
2012-05-30 18:13:09 +00:00
|
|
|
*/
|
|
|
|
|
2016-01-20 19:52:51 +00:00
|
|
|
#ifndef _INCLUDE__KERNEL__INTERFACE_H_
|
|
|
|
#define _INCLUDE__KERNEL__INTERFACE_H_
|
2012-05-30 18:13:09 +00:00
|
|
|
|
2014-03-15 00:26:53 +00:00
|
|
|
/* base-hw includes */
|
2016-05-18 10:20:04 +00:00
|
|
|
#include <kernel/types.h>
|
2013-11-14 16:29:34 +00:00
|
|
|
#include <kernel/interface_support.h>
|
2012-05-30 18:13:09 +00:00
|
|
|
|
2021-02-01 14:44:16 +00:00
|
|
|
namespace Kernel {
|
|
|
|
|
2012-05-30 18:13:09 +00:00
|
|
|
/**
|
2014-03-15 00:26:53 +00:00
|
|
|
* Kernel names of the kernel calls
|
2012-05-30 18:13:09 +00:00
|
|
|
*/
|
2017-02-24 13:29:29 +00:00
|
|
|
constexpr Call_arg call_id_stop_thread() { return 0; }
|
|
|
|
constexpr Call_arg call_id_restart_thread() { return 1; }
|
|
|
|
constexpr Call_arg call_id_yield_thread() { return 2; }
|
|
|
|
constexpr Call_arg call_id_send_request_msg() { return 3; }
|
|
|
|
constexpr Call_arg call_id_send_reply_msg() { return 4; }
|
|
|
|
constexpr Call_arg call_id_await_request_msg() { return 5; }
|
|
|
|
constexpr Call_arg call_id_kill_signal_context() { return 6; }
|
|
|
|
constexpr Call_arg call_id_submit_signal() { return 7; }
|
|
|
|
constexpr Call_arg call_id_await_signal() { return 8; }
|
2019-03-11 10:42:36 +00:00
|
|
|
constexpr Call_arg call_id_pending_signal() { return 9; }
|
|
|
|
constexpr Call_arg call_id_cancel_next_await_signal() { return 10; }
|
|
|
|
constexpr Call_arg call_id_ack_signal() { return 11; }
|
|
|
|
constexpr Call_arg call_id_print_char() { return 12; }
|
2020-03-03 14:56:50 +00:00
|
|
|
constexpr Call_arg call_id_cache_coherent_region() { return 13; }
|
2021-06-24 12:27:37 +00:00
|
|
|
constexpr Call_arg call_id_cache_clean_inv_region() { return 14; }
|
|
|
|
constexpr Call_arg call_id_cache_inv_region() { return 15; }
|
|
|
|
constexpr Call_arg call_id_ack_cap() { return 16; }
|
|
|
|
constexpr Call_arg call_id_delete_cap() { return 17; }
|
|
|
|
constexpr Call_arg call_id_timeout() { return 18; }
|
|
|
|
constexpr Call_arg call_id_timeout_max_us() { return 19; }
|
|
|
|
constexpr Call_arg call_id_time() { return 20; }
|
|
|
|
constexpr Call_arg call_id_run_vm() { return 21; }
|
|
|
|
constexpr Call_arg call_id_pause_vm() { return 22; }
|
2012-05-30 18:13:09 +00:00
|
|
|
|
2013-11-14 12:29:47 +00:00
|
|
|
|
2012-10-23 15:12:09 +00:00
|
|
|
/*****************************************************************
|
2013-11-14 16:29:34 +00:00
|
|
|
** Kernel call with 1 to 6 arguments **
|
2012-10-23 15:12:09 +00:00
|
|
|
** **
|
|
|
|
** These functions must not be inline to ensure that objects, **
|
|
|
|
** wich are referenced by arguments, are tagged as "used" even **
|
|
|
|
** though only the pointer gets handled in here. **
|
|
|
|
*****************************************************************/
|
|
|
|
|
2013-11-14 16:29:34 +00:00
|
|
|
Call_ret call(Call_arg arg_0);
|
2012-10-23 15:12:09 +00:00
|
|
|
|
2013-11-14 16:29:34 +00:00
|
|
|
Call_ret call(Call_arg arg_0,
|
|
|
|
Call_arg arg_1);
|
2012-10-23 15:12:09 +00:00
|
|
|
|
2013-11-14 16:29:34 +00:00
|
|
|
Call_ret call(Call_arg arg_0,
|
|
|
|
Call_arg arg_1,
|
|
|
|
Call_arg arg_2);
|
2012-10-23 15:12:09 +00:00
|
|
|
|
2013-11-14 16:29:34 +00:00
|
|
|
Call_ret call(Call_arg arg_0,
|
|
|
|
Call_arg arg_1,
|
|
|
|
Call_arg arg_2,
|
|
|
|
Call_arg arg_3);
|
2012-10-23 15:12:09 +00:00
|
|
|
|
2013-11-14 16:29:34 +00:00
|
|
|
Call_ret call(Call_arg arg_0,
|
|
|
|
Call_arg arg_1,
|
|
|
|
Call_arg arg_2,
|
|
|
|
Call_arg arg_3,
|
|
|
|
Call_arg arg_4);
|
2012-10-23 15:12:09 +00:00
|
|
|
|
2013-11-14 16:29:34 +00:00
|
|
|
Call_ret call(Call_arg arg_0,
|
|
|
|
Call_arg arg_1,
|
|
|
|
Call_arg arg_2,
|
|
|
|
Call_arg arg_3,
|
|
|
|
Call_arg arg_4,
|
|
|
|
Call_arg arg_5);
|
2012-10-23 15:12:09 +00:00
|
|
|
|
2019-02-21 16:23:10 +00:00
|
|
|
Call_ret_64 call64(Call_arg arg_0);
|
|
|
|
|
2012-05-30 18:13:09 +00:00
|
|
|
|
2016-05-18 10:20:04 +00:00
|
|
|
/**
|
|
|
|
* Install timeout for calling thread
|
|
|
|
*
|
|
|
|
* \param duration_us timeout duration in microseconds
|
|
|
|
* \param sigid local name of signal context to trigger
|
|
|
|
*
|
|
|
|
* This call always overwrites the last timeout installed by the thread
|
|
|
|
* if any.
|
|
|
|
*/
|
2019-02-21 16:23:10 +00:00
|
|
|
inline int timeout(timeout_t const duration_us, capid_t const sigid)
|
2016-05-18 10:20:04 +00:00
|
|
|
{
|
2021-12-02 10:21:14 +00:00
|
|
|
return (int)call(call_id_timeout(), duration_us, sigid);
|
2016-05-18 10:20:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
os/timer: interpolate time via timestamps
Previously, the Genode::Timer::curr_time always used the
Timer_session::elapsed_ms RPC as back end. Now, Genode::Timer reads
this remote time only in a periodic fashion independently from the calls
to Genode::Timer::curr_time. If now one calls Genode::Timer::curr_time,
the function takes the last read remote time value and adapts it using
the timestamp difference since the remote-time read. The conversion
factor from timestamps to time is estimated on every remote-time read
using the last read remote-time value and the timestamp difference since
the last remote time read.
This commit also re-works the timeout test. The test now has two stages.
In the first stage, it tests fast polling of the
Genode::Timer::curr_time. This stage checks the error between locally
interpolated and timer-driver time as well as wether the locally
interpolated time is monotone and sufficiently homogeneous. In the
second stage several periodic and one-shot timeouts are scheduled at
once. This stage checks if the timeouts trigger sufficiently precise.
This commit adds the new Kernel::time syscall to base-hw. The syscall is
solely used by the Genode::Timer on base-hw as substitute for the
timestamp. This is because on ARM, the timestamp function uses the ARM
performance counter that stops counting when the WFI (wait for
interrupt) instruction is active. This instruction, however is used by
the base-hw idle contexts that get active when no user thread needs to
be scheduled. Thus, the ARM performance counter is not a good choice for
time interpolation and we use the kernel internal time instead.
With this commit, the timeout library becomes a basic library. That means
that it is linked against the LDSO which then provides it to the program it
serves. Furthermore, you can't use the timeout library anymore without the
LDSO because through the kernel-dependent LDSO make-files we can achieve a
kernel-dependent timeout implementation.
This commit introduces a structured Duration type that shall successively
replace the use of Microseconds, Milliseconds, and integer types for duration
values.
Open issues:
* The timeout test fails on Raspberry PI because of precision errors in the
first stage. However, this does not render the framework unusable in general
on the RPI but merely is an issue when speaking of microseconds precision.
* If we run on ARM with another Kernel than HW the timestamp speed may
continuously vary from almost 0 up to CPU speed. The Timer, however,
only uses interpolation if the timestamp speed remained stable (12.5%
tolerance) for at least 3 observation periods. Currently, one period is
100ms, so its 300ms. As long as this is not the case,
Timer_session::elapsed_ms is called instead.
Anyway, it might happen that the CPU load was stable for some time so
interpolation becomes active and now the timestamp speed drops. In the
worst case, we would now have 100ms of slowed down time. The bad thing
about it would be, that this also affects the timeout of the period.
Thus, it might "freeze" the local time for more than 100ms.
On the other hand, if the timestamp speed suddenly raises after some
stable time, interpolated time can get too fast. This would shorten the
period but nonetheless may result in drifting away into the far future.
Now we would have the problem that we can't deliver the real time
anymore until it has caught up because the output of Timer::curr_time
shall be monotone. So, effectively local time might "freeze" again for
more than 100ms.
It would be a solution to not use the Trace::timestamp on ARM w/o HW but
a function whose return value causes the Timer to never use
interpolation because of its stability policy.
Fixes #2400
2017-04-21 22:52:23 +00:00
|
|
|
/**
|
|
|
|
* Return value of a free-running, uniform counter
|
|
|
|
*
|
|
|
|
* The counter has a constant frequency and does not wrap twice during
|
|
|
|
* a time period of 'timeout_max_us()' microseconds.
|
|
|
|
*/
|
|
|
|
inline time_t time()
|
|
|
|
{
|
2019-02-21 16:23:10 +00:00
|
|
|
return call64(call_id_time());
|
os/timer: interpolate time via timestamps
Previously, the Genode::Timer::curr_time always used the
Timer_session::elapsed_ms RPC as back end. Now, Genode::Timer reads
this remote time only in a periodic fashion independently from the calls
to Genode::Timer::curr_time. If now one calls Genode::Timer::curr_time,
the function takes the last read remote time value and adapts it using
the timestamp difference since the remote-time read. The conversion
factor from timestamps to time is estimated on every remote-time read
using the last read remote-time value and the timestamp difference since
the last remote time read.
This commit also re-works the timeout test. The test now has two stages.
In the first stage, it tests fast polling of the
Genode::Timer::curr_time. This stage checks the error between locally
interpolated and timer-driver time as well as wether the locally
interpolated time is monotone and sufficiently homogeneous. In the
second stage several periodic and one-shot timeouts are scheduled at
once. This stage checks if the timeouts trigger sufficiently precise.
This commit adds the new Kernel::time syscall to base-hw. The syscall is
solely used by the Genode::Timer on base-hw as substitute for the
timestamp. This is because on ARM, the timestamp function uses the ARM
performance counter that stops counting when the WFI (wait for
interrupt) instruction is active. This instruction, however is used by
the base-hw idle contexts that get active when no user thread needs to
be scheduled. Thus, the ARM performance counter is not a good choice for
time interpolation and we use the kernel internal time instead.
With this commit, the timeout library becomes a basic library. That means
that it is linked against the LDSO which then provides it to the program it
serves. Furthermore, you can't use the timeout library anymore without the
LDSO because through the kernel-dependent LDSO make-files we can achieve a
kernel-dependent timeout implementation.
This commit introduces a structured Duration type that shall successively
replace the use of Microseconds, Milliseconds, and integer types for duration
values.
Open issues:
* The timeout test fails on Raspberry PI because of precision errors in the
first stage. However, this does not render the framework unusable in general
on the RPI but merely is an issue when speaking of microseconds precision.
* If we run on ARM with another Kernel than HW the timestamp speed may
continuously vary from almost 0 up to CPU speed. The Timer, however,
only uses interpolation if the timestamp speed remained stable (12.5%
tolerance) for at least 3 observation periods. Currently, one period is
100ms, so its 300ms. As long as this is not the case,
Timer_session::elapsed_ms is called instead.
Anyway, it might happen that the CPU load was stable for some time so
interpolation becomes active and now the timestamp speed drops. In the
worst case, we would now have 100ms of slowed down time. The bad thing
about it would be, that this also affects the timeout of the period.
Thus, it might "freeze" the local time for more than 100ms.
On the other hand, if the timestamp speed suddenly raises after some
stable time, interpolated time can get too fast. This would shorten the
period but nonetheless may result in drifting away into the far future.
Now we would have the problem that we can't deliver the real time
anymore until it has caught up because the output of Timer::curr_time
shall be monotone. So, effectively local time might "freeze" again for
more than 100ms.
It would be a solution to not use the Trace::timestamp on ARM w/o HW but
a function whose return value causes the Timer to never use
interpolation because of its stability policy.
Fixes #2400
2017-04-21 22:52:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-05-18 10:20:04 +00:00
|
|
|
/**
|
|
|
|
* Return the constant maximum installable timeout in microseconds
|
|
|
|
*
|
|
|
|
* The return value is also the maximum delay to call 'timeout_age_us'
|
|
|
|
* for a timeout after its installation.
|
|
|
|
*/
|
|
|
|
inline time_t timeout_max_us()
|
|
|
|
{
|
2019-02-21 16:23:10 +00:00
|
|
|
return call64(call_id_timeout_max_us());
|
2016-05-18 10:20:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-05-30 18:13:09 +00:00
|
|
|
/**
|
hw: clean up scheduling-readiness syscalls
This cleans up the syscalls that are mainly used to control the
scheduling readiness of a thread. The different use cases and
requirements were somehow mixed together in the previous interface. The
new syscall set is:
1) pause_thread and resume_thread
They don't affect the state of the thread (IPC, signalling, etc.) but
merely decide wether the thread is allowed for scheduling or not, the
so-called pause state. The pause state is orthogonal to the thread state
and masks it when it comes to scheduling. In contrast to the stopped
state, which is described in "stop_thread and restart_thread", the
thread state and the UTCB content of a thread may change while in the
paused state. However, the register state of a thread doesn't change
while paused. The "pause" and "resume" syscalls are both core-restricted
and may target any thread. They are used as back end for the CPU session
calls "pause" and "resume". The "pause/resume" feature is made for
applications like the GDB monitor that transparently want to stop and
continue the execution of a thread no matter what state the thread is
in.
2) stop_thread and restart_thread
The stop syscall can only be used on a thread in the non-blocking
("active") thread state. The thread then switches to the "stopped"
thread state in wich it explicitely waits for a restart. The restart
syscall can only be used on a thread in the "stopped" or the "active"
thread state. The thread then switches back to the "active" thread state
and the syscall returns whether the thread was stopped. Both syscalls
are not core-restricted. "Stop" always targets the calling thread while
"restart" may target any thread in the same PD as the caller. Thread
state and UTCB content of a thread don't change while in the stopped
state. The "stop/restart" feature is used when an active thread wants to
wait for an event that is not known to the kernel. Actually the syscalls
are used when waiting for locks and on thread exit.
3) cancel_thread_blocking
Does cleanly cancel a cancelable blocking thread state (IPC, signalling,
stopped). The thread whose blocking was cancelled goes back to the
"active" thread state. It may receive a syscall return value that
reflects the cancellation. This syscall doesn't affect the pause state
of the thread which means that it may still not get scheduled. The
syscall is core-restricted and may target any thread.
4) yield_thread
Does its best that a thread is scheduled as few as possible in the
current scheduling super-period without touching the thread or pause
state. In the next superperiod, however, the thread is scheduled
"normal" again. The syscall is not core-restricted and always targets
the caller.
Fixes #2104
2016-09-15 15:23:06 +00:00
|
|
|
* Wait for a user event signaled by a 'restart_thread' syscall
|
|
|
|
*
|
|
|
|
* The stop syscall always targets the calling thread that, therefore must
|
|
|
|
* be in the 'active' thread state. The thread then switches to the
|
|
|
|
* 'stopped' thread state in wich it waits for a restart. The restart
|
|
|
|
* syscall can only be used on a thread in the 'stopped' or the 'active'
|
|
|
|
* thread state. The thread then switches back to the 'active' thread
|
|
|
|
* state and the syscall returns whether the thread was stopped. Both
|
|
|
|
* syscalls are not core-restricted. In contrast to the 'stop' syscall,
|
|
|
|
* 'restart' may target any thread in the same PD as the caller. Thread
|
|
|
|
* state and UTCB content of a thread don't change while in the 'stopped'
|
|
|
|
* state. The 'stop/restart' feature is used when an active thread wants
|
|
|
|
* to wait for an event that is not known to the kernel. Actually, the
|
|
|
|
* syscalls are used when waiting for locks and when doing infinite
|
|
|
|
* waiting on thread exit.
|
2012-05-30 18:13:09 +00:00
|
|
|
*/
|
hw: clean up scheduling-readiness syscalls
This cleans up the syscalls that are mainly used to control the
scheduling readiness of a thread. The different use cases and
requirements were somehow mixed together in the previous interface. The
new syscall set is:
1) pause_thread and resume_thread
They don't affect the state of the thread (IPC, signalling, etc.) but
merely decide wether the thread is allowed for scheduling or not, the
so-called pause state. The pause state is orthogonal to the thread state
and masks it when it comes to scheduling. In contrast to the stopped
state, which is described in "stop_thread and restart_thread", the
thread state and the UTCB content of a thread may change while in the
paused state. However, the register state of a thread doesn't change
while paused. The "pause" and "resume" syscalls are both core-restricted
and may target any thread. They are used as back end for the CPU session
calls "pause" and "resume". The "pause/resume" feature is made for
applications like the GDB monitor that transparently want to stop and
continue the execution of a thread no matter what state the thread is
in.
2) stop_thread and restart_thread
The stop syscall can only be used on a thread in the non-blocking
("active") thread state. The thread then switches to the "stopped"
thread state in wich it explicitely waits for a restart. The restart
syscall can only be used on a thread in the "stopped" or the "active"
thread state. The thread then switches back to the "active" thread state
and the syscall returns whether the thread was stopped. Both syscalls
are not core-restricted. "Stop" always targets the calling thread while
"restart" may target any thread in the same PD as the caller. Thread
state and UTCB content of a thread don't change while in the stopped
state. The "stop/restart" feature is used when an active thread wants to
wait for an event that is not known to the kernel. Actually the syscalls
are used when waiting for locks and on thread exit.
3) cancel_thread_blocking
Does cleanly cancel a cancelable blocking thread state (IPC, signalling,
stopped). The thread whose blocking was cancelled goes back to the
"active" thread state. It may receive a syscall return value that
reflects the cancellation. This syscall doesn't affect the pause state
of the thread which means that it may still not get scheduled. The
syscall is core-restricted and may target any thread.
4) yield_thread
Does its best that a thread is scheduled as few as possible in the
current scheduling super-period without touching the thread or pause
state. In the next superperiod, however, the thread is scheduled
"normal" again. The syscall is not core-restricted and always targets
the caller.
Fixes #2104
2016-09-15 15:23:06 +00:00
|
|
|
inline void stop_thread()
|
2013-11-14 12:29:47 +00:00
|
|
|
{
|
hw: clean up scheduling-readiness syscalls
This cleans up the syscalls that are mainly used to control the
scheduling readiness of a thread. The different use cases and
requirements were somehow mixed together in the previous interface. The
new syscall set is:
1) pause_thread and resume_thread
They don't affect the state of the thread (IPC, signalling, etc.) but
merely decide wether the thread is allowed for scheduling or not, the
so-called pause state. The pause state is orthogonal to the thread state
and masks it when it comes to scheduling. In contrast to the stopped
state, which is described in "stop_thread and restart_thread", the
thread state and the UTCB content of a thread may change while in the
paused state. However, the register state of a thread doesn't change
while paused. The "pause" and "resume" syscalls are both core-restricted
and may target any thread. They are used as back end for the CPU session
calls "pause" and "resume". The "pause/resume" feature is made for
applications like the GDB monitor that transparently want to stop and
continue the execution of a thread no matter what state the thread is
in.
2) stop_thread and restart_thread
The stop syscall can only be used on a thread in the non-blocking
("active") thread state. The thread then switches to the "stopped"
thread state in wich it explicitely waits for a restart. The restart
syscall can only be used on a thread in the "stopped" or the "active"
thread state. The thread then switches back to the "active" thread state
and the syscall returns whether the thread was stopped. Both syscalls
are not core-restricted. "Stop" always targets the calling thread while
"restart" may target any thread in the same PD as the caller. Thread
state and UTCB content of a thread don't change while in the stopped
state. The "stop/restart" feature is used when an active thread wants to
wait for an event that is not known to the kernel. Actually the syscalls
are used when waiting for locks and on thread exit.
3) cancel_thread_blocking
Does cleanly cancel a cancelable blocking thread state (IPC, signalling,
stopped). The thread whose blocking was cancelled goes back to the
"active" thread state. It may receive a syscall return value that
reflects the cancellation. This syscall doesn't affect the pause state
of the thread which means that it may still not get scheduled. The
syscall is core-restricted and may target any thread.
4) yield_thread
Does its best that a thread is scheduled as few as possible in the
current scheduling super-period without touching the thread or pause
state. In the next superperiod, however, the thread is scheduled
"normal" again. The syscall is not core-restricted and always targets
the caller.
Fixes #2104
2016-09-15 15:23:06 +00:00
|
|
|
call(call_id_stop_thread());
|
2013-11-14 12:29:47 +00:00
|
|
|
}
|
2012-05-30 18:13:09 +00:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
hw: clean up scheduling-readiness syscalls
This cleans up the syscalls that are mainly used to control the
scheduling readiness of a thread. The different use cases and
requirements were somehow mixed together in the previous interface. The
new syscall set is:
1) pause_thread and resume_thread
They don't affect the state of the thread (IPC, signalling, etc.) but
merely decide wether the thread is allowed for scheduling or not, the
so-called pause state. The pause state is orthogonal to the thread state
and masks it when it comes to scheduling. In contrast to the stopped
state, which is described in "stop_thread and restart_thread", the
thread state and the UTCB content of a thread may change while in the
paused state. However, the register state of a thread doesn't change
while paused. The "pause" and "resume" syscalls are both core-restricted
and may target any thread. They are used as back end for the CPU session
calls "pause" and "resume". The "pause/resume" feature is made for
applications like the GDB monitor that transparently want to stop and
continue the execution of a thread no matter what state the thread is
in.
2) stop_thread and restart_thread
The stop syscall can only be used on a thread in the non-blocking
("active") thread state. The thread then switches to the "stopped"
thread state in wich it explicitely waits for a restart. The restart
syscall can only be used on a thread in the "stopped" or the "active"
thread state. The thread then switches back to the "active" thread state
and the syscall returns whether the thread was stopped. Both syscalls
are not core-restricted. "Stop" always targets the calling thread while
"restart" may target any thread in the same PD as the caller. Thread
state and UTCB content of a thread don't change while in the stopped
state. The "stop/restart" feature is used when an active thread wants to
wait for an event that is not known to the kernel. Actually the syscalls
are used when waiting for locks and on thread exit.
3) cancel_thread_blocking
Does cleanly cancel a cancelable blocking thread state (IPC, signalling,
stopped). The thread whose blocking was cancelled goes back to the
"active" thread state. It may receive a syscall return value that
reflects the cancellation. This syscall doesn't affect the pause state
of the thread which means that it may still not get scheduled. The
syscall is core-restricted and may target any thread.
4) yield_thread
Does its best that a thread is scheduled as few as possible in the
current scheduling super-period without touching the thread or pause
state. In the next superperiod, however, the thread is scheduled
"normal" again. The syscall is not core-restricted and always targets
the caller.
Fixes #2104
2016-09-15 15:23:06 +00:00
|
|
|
* End blocking of a stopped thread
|
2012-05-30 18:13:09 +00:00
|
|
|
*
|
2015-05-19 12:18:40 +00:00
|
|
|
* \param thread_id capability id of the targeted thread
|
2012-05-30 18:13:09 +00:00
|
|
|
*
|
hw: clean up scheduling-readiness syscalls
This cleans up the syscalls that are mainly used to control the
scheduling readiness of a thread. The different use cases and
requirements were somehow mixed together in the previous interface. The
new syscall set is:
1) pause_thread and resume_thread
They don't affect the state of the thread (IPC, signalling, etc.) but
merely decide wether the thread is allowed for scheduling or not, the
so-called pause state. The pause state is orthogonal to the thread state
and masks it when it comes to scheduling. In contrast to the stopped
state, which is described in "stop_thread and restart_thread", the
thread state and the UTCB content of a thread may change while in the
paused state. However, the register state of a thread doesn't change
while paused. The "pause" and "resume" syscalls are both core-restricted
and may target any thread. They are used as back end for the CPU session
calls "pause" and "resume". The "pause/resume" feature is made for
applications like the GDB monitor that transparently want to stop and
continue the execution of a thread no matter what state the thread is
in.
2) stop_thread and restart_thread
The stop syscall can only be used on a thread in the non-blocking
("active") thread state. The thread then switches to the "stopped"
thread state in wich it explicitely waits for a restart. The restart
syscall can only be used on a thread in the "stopped" or the "active"
thread state. The thread then switches back to the "active" thread state
and the syscall returns whether the thread was stopped. Both syscalls
are not core-restricted. "Stop" always targets the calling thread while
"restart" may target any thread in the same PD as the caller. Thread
state and UTCB content of a thread don't change while in the stopped
state. The "stop/restart" feature is used when an active thread wants to
wait for an event that is not known to the kernel. Actually the syscalls
are used when waiting for locks and on thread exit.
3) cancel_thread_blocking
Does cleanly cancel a cancelable blocking thread state (IPC, signalling,
stopped). The thread whose blocking was cancelled goes back to the
"active" thread state. It may receive a syscall return value that
reflects the cancellation. This syscall doesn't affect the pause state
of the thread which means that it may still not get scheduled. The
syscall is core-restricted and may target any thread.
4) yield_thread
Does its best that a thread is scheduled as few as possible in the
current scheduling super-period without touching the thread or pause
state. In the next superperiod, however, the thread is scheduled
"normal" again. The syscall is not core-restricted and always targets
the caller.
Fixes #2104
2016-09-15 15:23:06 +00:00
|
|
|
* \return wether the thread was stopped beforehand
|
|
|
|
*
|
|
|
|
* For details see the 'stop_thread' syscall.
|
2012-05-30 18:13:09 +00:00
|
|
|
*/
|
hw: clean up scheduling-readiness syscalls
This cleans up the syscalls that are mainly used to control the
scheduling readiness of a thread. The different use cases and
requirements were somehow mixed together in the previous interface. The
new syscall set is:
1) pause_thread and resume_thread
They don't affect the state of the thread (IPC, signalling, etc.) but
merely decide wether the thread is allowed for scheduling or not, the
so-called pause state. The pause state is orthogonal to the thread state
and masks it when it comes to scheduling. In contrast to the stopped
state, which is described in "stop_thread and restart_thread", the
thread state and the UTCB content of a thread may change while in the
paused state. However, the register state of a thread doesn't change
while paused. The "pause" and "resume" syscalls are both core-restricted
and may target any thread. They are used as back end for the CPU session
calls "pause" and "resume". The "pause/resume" feature is made for
applications like the GDB monitor that transparently want to stop and
continue the execution of a thread no matter what state the thread is
in.
2) stop_thread and restart_thread
The stop syscall can only be used on a thread in the non-blocking
("active") thread state. The thread then switches to the "stopped"
thread state in wich it explicitely waits for a restart. The restart
syscall can only be used on a thread in the "stopped" or the "active"
thread state. The thread then switches back to the "active" thread state
and the syscall returns whether the thread was stopped. Both syscalls
are not core-restricted. "Stop" always targets the calling thread while
"restart" may target any thread in the same PD as the caller. Thread
state and UTCB content of a thread don't change while in the stopped
state. The "stop/restart" feature is used when an active thread wants to
wait for an event that is not known to the kernel. Actually the syscalls
are used when waiting for locks and on thread exit.
3) cancel_thread_blocking
Does cleanly cancel a cancelable blocking thread state (IPC, signalling,
stopped). The thread whose blocking was cancelled goes back to the
"active" thread state. It may receive a syscall return value that
reflects the cancellation. This syscall doesn't affect the pause state
of the thread which means that it may still not get scheduled. The
syscall is core-restricted and may target any thread.
4) yield_thread
Does its best that a thread is scheduled as few as possible in the
current scheduling super-period without touching the thread or pause
state. In the next superperiod, however, the thread is scheduled
"normal" again. The syscall is not core-restricted and always targets
the caller.
Fixes #2104
2016-09-15 15:23:06 +00:00
|
|
|
inline bool restart_thread(capid_t const thread_id)
|
2013-11-14 12:29:47 +00:00
|
|
|
{
|
hw: clean up scheduling-readiness syscalls
This cleans up the syscalls that are mainly used to control the
scheduling readiness of a thread. The different use cases and
requirements were somehow mixed together in the previous interface. The
new syscall set is:
1) pause_thread and resume_thread
They don't affect the state of the thread (IPC, signalling, etc.) but
merely decide wether the thread is allowed for scheduling or not, the
so-called pause state. The pause state is orthogonal to the thread state
and masks it when it comes to scheduling. In contrast to the stopped
state, which is described in "stop_thread and restart_thread", the
thread state and the UTCB content of a thread may change while in the
paused state. However, the register state of a thread doesn't change
while paused. The "pause" and "resume" syscalls are both core-restricted
and may target any thread. They are used as back end for the CPU session
calls "pause" and "resume". The "pause/resume" feature is made for
applications like the GDB monitor that transparently want to stop and
continue the execution of a thread no matter what state the thread is
in.
2) stop_thread and restart_thread
The stop syscall can only be used on a thread in the non-blocking
("active") thread state. The thread then switches to the "stopped"
thread state in wich it explicitely waits for a restart. The restart
syscall can only be used on a thread in the "stopped" or the "active"
thread state. The thread then switches back to the "active" thread state
and the syscall returns whether the thread was stopped. Both syscalls
are not core-restricted. "Stop" always targets the calling thread while
"restart" may target any thread in the same PD as the caller. Thread
state and UTCB content of a thread don't change while in the stopped
state. The "stop/restart" feature is used when an active thread wants to
wait for an event that is not known to the kernel. Actually the syscalls
are used when waiting for locks and on thread exit.
3) cancel_thread_blocking
Does cleanly cancel a cancelable blocking thread state (IPC, signalling,
stopped). The thread whose blocking was cancelled goes back to the
"active" thread state. It may receive a syscall return value that
reflects the cancellation. This syscall doesn't affect the pause state
of the thread which means that it may still not get scheduled. The
syscall is core-restricted and may target any thread.
4) yield_thread
Does its best that a thread is scheduled as few as possible in the
current scheduling super-period without touching the thread or pause
state. In the next superperiod, however, the thread is scheduled
"normal" again. The syscall is not core-restricted and always targets
the caller.
Fixes #2104
2016-09-15 15:23:06 +00:00
|
|
|
return call(call_id_restart_thread(), thread_id);
|
2013-11-14 12:29:47 +00:00
|
|
|
}
|
2012-11-09 16:10:38 +00:00
|
|
|
|
|
|
|
|
2012-05-30 18:13:09 +00:00
|
|
|
/**
|
hw: clean up scheduling-readiness syscalls
This cleans up the syscalls that are mainly used to control the
scheduling readiness of a thread. The different use cases and
requirements were somehow mixed together in the previous interface. The
new syscall set is:
1) pause_thread and resume_thread
They don't affect the state of the thread (IPC, signalling, etc.) but
merely decide wether the thread is allowed for scheduling or not, the
so-called pause state. The pause state is orthogonal to the thread state
and masks it when it comes to scheduling. In contrast to the stopped
state, which is described in "stop_thread and restart_thread", the
thread state and the UTCB content of a thread may change while in the
paused state. However, the register state of a thread doesn't change
while paused. The "pause" and "resume" syscalls are both core-restricted
and may target any thread. They are used as back end for the CPU session
calls "pause" and "resume". The "pause/resume" feature is made for
applications like the GDB monitor that transparently want to stop and
continue the execution of a thread no matter what state the thread is
in.
2) stop_thread and restart_thread
The stop syscall can only be used on a thread in the non-blocking
("active") thread state. The thread then switches to the "stopped"
thread state in wich it explicitely waits for a restart. The restart
syscall can only be used on a thread in the "stopped" or the "active"
thread state. The thread then switches back to the "active" thread state
and the syscall returns whether the thread was stopped. Both syscalls
are not core-restricted. "Stop" always targets the calling thread while
"restart" may target any thread in the same PD as the caller. Thread
state and UTCB content of a thread don't change while in the stopped
state. The "stop/restart" feature is used when an active thread wants to
wait for an event that is not known to the kernel. Actually the syscalls
are used when waiting for locks and on thread exit.
3) cancel_thread_blocking
Does cleanly cancel a cancelable blocking thread state (IPC, signalling,
stopped). The thread whose blocking was cancelled goes back to the
"active" thread state. It may receive a syscall return value that
reflects the cancellation. This syscall doesn't affect the pause state
of the thread which means that it may still not get scheduled. The
syscall is core-restricted and may target any thread.
4) yield_thread
Does its best that a thread is scheduled as few as possible in the
current scheduling super-period without touching the thread or pause
state. In the next superperiod, however, the thread is scheduled
"normal" again. The syscall is not core-restricted and always targets
the caller.
Fixes #2104
2016-09-15 15:23:06 +00:00
|
|
|
* Yield the callers remaining CPU time for this super period
|
2013-11-25 09:57:07 +00:00
|
|
|
*
|
hw: clean up scheduling-readiness syscalls
This cleans up the syscalls that are mainly used to control the
scheduling readiness of a thread. The different use cases and
requirements were somehow mixed together in the previous interface. The
new syscall set is:
1) pause_thread and resume_thread
They don't affect the state of the thread (IPC, signalling, etc.) but
merely decide wether the thread is allowed for scheduling or not, the
so-called pause state. The pause state is orthogonal to the thread state
and masks it when it comes to scheduling. In contrast to the stopped
state, which is described in "stop_thread and restart_thread", the
thread state and the UTCB content of a thread may change while in the
paused state. However, the register state of a thread doesn't change
while paused. The "pause" and "resume" syscalls are both core-restricted
and may target any thread. They are used as back end for the CPU session
calls "pause" and "resume". The "pause/resume" feature is made for
applications like the GDB monitor that transparently want to stop and
continue the execution of a thread no matter what state the thread is
in.
2) stop_thread and restart_thread
The stop syscall can only be used on a thread in the non-blocking
("active") thread state. The thread then switches to the "stopped"
thread state in wich it explicitely waits for a restart. The restart
syscall can only be used on a thread in the "stopped" or the "active"
thread state. The thread then switches back to the "active" thread state
and the syscall returns whether the thread was stopped. Both syscalls
are not core-restricted. "Stop" always targets the calling thread while
"restart" may target any thread in the same PD as the caller. Thread
state and UTCB content of a thread don't change while in the stopped
state. The "stop/restart" feature is used when an active thread wants to
wait for an event that is not known to the kernel. Actually the syscalls
are used when waiting for locks and on thread exit.
3) cancel_thread_blocking
Does cleanly cancel a cancelable blocking thread state (IPC, signalling,
stopped). The thread whose blocking was cancelled goes back to the
"active" thread state. It may receive a syscall return value that
reflects the cancellation. This syscall doesn't affect the pause state
of the thread which means that it may still not get scheduled. The
syscall is core-restricted and may target any thread.
4) yield_thread
Does its best that a thread is scheduled as few as possible in the
current scheduling super-period without touching the thread or pause
state. In the next superperiod, however, the thread is scheduled
"normal" again. The syscall is not core-restricted and always targets
the caller.
Fixes #2104
2016-09-15 15:23:06 +00:00
|
|
|
* Does its best that the caller is scheduled as few as possible in the
|
|
|
|
* current scheduling super-period without touching the thread or pause
|
|
|
|
* state of the thread. In the next superperiod, however, the thread is
|
|
|
|
* scheduled 'normal' again. The syscall is not core-restricted and always
|
|
|
|
* targets the caller. It is actually used in locks to help another thread
|
|
|
|
* reach a desired point in execution by releasing pressure from the CPU.
|
2012-05-30 18:13:09 +00:00
|
|
|
*/
|
hw: clean up scheduling-readiness syscalls
This cleans up the syscalls that are mainly used to control the
scheduling readiness of a thread. The different use cases and
requirements were somehow mixed together in the previous interface. The
new syscall set is:
1) pause_thread and resume_thread
They don't affect the state of the thread (IPC, signalling, etc.) but
merely decide wether the thread is allowed for scheduling or not, the
so-called pause state. The pause state is orthogonal to the thread state
and masks it when it comes to scheduling. In contrast to the stopped
state, which is described in "stop_thread and restart_thread", the
thread state and the UTCB content of a thread may change while in the
paused state. However, the register state of a thread doesn't change
while paused. The "pause" and "resume" syscalls are both core-restricted
and may target any thread. They are used as back end for the CPU session
calls "pause" and "resume". The "pause/resume" feature is made for
applications like the GDB monitor that transparently want to stop and
continue the execution of a thread no matter what state the thread is
in.
2) stop_thread and restart_thread
The stop syscall can only be used on a thread in the non-blocking
("active") thread state. The thread then switches to the "stopped"
thread state in wich it explicitely waits for a restart. The restart
syscall can only be used on a thread in the "stopped" or the "active"
thread state. The thread then switches back to the "active" thread state
and the syscall returns whether the thread was stopped. Both syscalls
are not core-restricted. "Stop" always targets the calling thread while
"restart" may target any thread in the same PD as the caller. Thread
state and UTCB content of a thread don't change while in the stopped
state. The "stop/restart" feature is used when an active thread wants to
wait for an event that is not known to the kernel. Actually the syscalls
are used when waiting for locks and on thread exit.
3) cancel_thread_blocking
Does cleanly cancel a cancelable blocking thread state (IPC, signalling,
stopped). The thread whose blocking was cancelled goes back to the
"active" thread state. It may receive a syscall return value that
reflects the cancellation. This syscall doesn't affect the pause state
of the thread which means that it may still not get scheduled. The
syscall is core-restricted and may target any thread.
4) yield_thread
Does its best that a thread is scheduled as few as possible in the
current scheduling super-period without touching the thread or pause
state. In the next superperiod, however, the thread is scheduled
"normal" again. The syscall is not core-restricted and always targets
the caller.
Fixes #2104
2016-09-15 15:23:06 +00:00
|
|
|
inline void yield_thread()
|
2013-11-14 12:29:47 +00:00
|
|
|
{
|
hw: clean up scheduling-readiness syscalls
This cleans up the syscalls that are mainly used to control the
scheduling readiness of a thread. The different use cases and
requirements were somehow mixed together in the previous interface. The
new syscall set is:
1) pause_thread and resume_thread
They don't affect the state of the thread (IPC, signalling, etc.) but
merely decide wether the thread is allowed for scheduling or not, the
so-called pause state. The pause state is orthogonal to the thread state
and masks it when it comes to scheduling. In contrast to the stopped
state, which is described in "stop_thread and restart_thread", the
thread state and the UTCB content of a thread may change while in the
paused state. However, the register state of a thread doesn't change
while paused. The "pause" and "resume" syscalls are both core-restricted
and may target any thread. They are used as back end for the CPU session
calls "pause" and "resume". The "pause/resume" feature is made for
applications like the GDB monitor that transparently want to stop and
continue the execution of a thread no matter what state the thread is
in.
2) stop_thread and restart_thread
The stop syscall can only be used on a thread in the non-blocking
("active") thread state. The thread then switches to the "stopped"
thread state in wich it explicitely waits for a restart. The restart
syscall can only be used on a thread in the "stopped" or the "active"
thread state. The thread then switches back to the "active" thread state
and the syscall returns whether the thread was stopped. Both syscalls
are not core-restricted. "Stop" always targets the calling thread while
"restart" may target any thread in the same PD as the caller. Thread
state and UTCB content of a thread don't change while in the stopped
state. The "stop/restart" feature is used when an active thread wants to
wait for an event that is not known to the kernel. Actually the syscalls
are used when waiting for locks and on thread exit.
3) cancel_thread_blocking
Does cleanly cancel a cancelable blocking thread state (IPC, signalling,
stopped). The thread whose blocking was cancelled goes back to the
"active" thread state. It may receive a syscall return value that
reflects the cancellation. This syscall doesn't affect the pause state
of the thread which means that it may still not get scheduled. The
syscall is core-restricted and may target any thread.
4) yield_thread
Does its best that a thread is scheduled as few as possible in the
current scheduling super-period without touching the thread or pause
state. In the next superperiod, however, the thread is scheduled
"normal" again. The syscall is not core-restricted and always targets
the caller.
Fixes #2104
2016-09-15 15:23:06 +00:00
|
|
|
call(call_id_yield_thread());
|
2013-09-18 20:33:56 +00:00
|
|
|
}
|
2012-05-30 18:13:09 +00:00
|
|
|
|
2014-04-07 13:52:21 +00:00
|
|
|
/**
|
2020-03-03 14:56:50 +00:00
|
|
|
* Enforce coherent view (I-/D-Caches) on memory region
|
2014-04-07 13:52:21 +00:00
|
|
|
*
|
|
|
|
* \param base base of the region within the current domain
|
|
|
|
* \param size size of the region
|
|
|
|
*/
|
2020-03-03 14:56:50 +00:00
|
|
|
inline void cache_coherent_region(addr_t const base, size_t const size)
|
2014-04-07 13:52:21 +00:00
|
|
|
{
|
2020-03-03 14:56:50 +00:00
|
|
|
call(call_id_cache_coherent_region(), (Call_arg)base, (Call_arg)size);
|
2014-04-07 13:52:21 +00:00
|
|
|
}
|
2012-05-30 18:13:09 +00:00
|
|
|
|
2014-04-07 14:18:43 +00:00
|
|
|
|
2021-06-24 12:27:37 +00:00
|
|
|
/**
|
|
|
|
* Clean and invalidate D-Cache lines of the given memory region
|
|
|
|
*
|
|
|
|
* \param base base of the region within the current domain
|
|
|
|
* \param size size of the region
|
|
|
|
*/
|
|
|
|
inline void cache_clean_invalidate_data_region(addr_t const base,
|
|
|
|
size_t const size)
|
|
|
|
{
|
|
|
|
call(call_id_cache_clean_inv_region(), (Call_arg)base, (Call_arg)size);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Invalidate D-Cache lines of the given memory region
|
|
|
|
*
|
|
|
|
* \param base base of the region within the current domain
|
|
|
|
* \param size size of the region
|
|
|
|
*/
|
|
|
|
inline void cache_invalidate_data_region(addr_t const base,
|
|
|
|
size_t const size)
|
|
|
|
{
|
|
|
|
call(call_id_cache_inv_region(), (Call_arg)base, (Call_arg)size);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-05-30 18:13:09 +00:00
|
|
|
/**
|
2013-11-21 11:04:21 +00:00
|
|
|
* Send request message and await receipt of corresponding reply message
|
2012-05-30 18:13:09 +00:00
|
|
|
*
|
2015-05-19 12:18:40 +00:00
|
|
|
* \param thread_id capability id of targeted thread
|
2012-05-30 18:13:09 +00:00
|
|
|
*
|
2013-11-21 11:04:21 +00:00
|
|
|
* \retval 0 succeeded
|
|
|
|
* \retval -1 failed
|
2015-05-19 12:18:40 +00:00
|
|
|
* \retval -2 failed due to out-of-memory for capability reception
|
2013-11-21 11:04:21 +00:00
|
|
|
*
|
|
|
|
* If the call returns successful, the received message is located at the
|
|
|
|
* base of the callers userland thread-context.
|
2012-05-30 18:13:09 +00:00
|
|
|
*/
|
2015-05-19 12:18:40 +00:00
|
|
|
inline int send_request_msg(capid_t const thread_id, unsigned rcv_caps)
|
2013-10-07 14:01:03 +00:00
|
|
|
{
|
2021-12-02 10:21:14 +00:00
|
|
|
return (int)call(call_id_send_request_msg(), thread_id, rcv_caps);
|
2013-10-07 14:01:03 +00:00
|
|
|
}
|
2012-05-30 18:13:09 +00:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
2013-11-21 11:04:21 +00:00
|
|
|
* Await receipt of request message
|
2012-05-30 18:13:09 +00:00
|
|
|
*
|
2015-05-19 12:18:40 +00:00
|
|
|
* \param rcv_caps number of capabilities willing to accept
|
|
|
|
*
|
2013-11-21 11:04:21 +00:00
|
|
|
* \retval 0 succeeded
|
2015-05-19 12:18:40 +00:00
|
|
|
* \retval -1 canceled
|
|
|
|
* \retval -2 failed due to out-of-memory for capability reception
|
2013-10-17 11:51:17 +00:00
|
|
|
*
|
2013-11-21 11:04:21 +00:00
|
|
|
* If the call returns successful, the received message is located at the
|
|
|
|
* base of the callers userland thread-context.
|
2012-05-30 18:13:09 +00:00
|
|
|
*/
|
2015-05-19 12:18:40 +00:00
|
|
|
inline int await_request_msg(unsigned rcv_caps)
|
2013-10-17 11:51:17 +00:00
|
|
|
{
|
2021-12-02 10:21:14 +00:00
|
|
|
return (int)call(call_id_await_request_msg(), rcv_caps);
|
2013-10-17 11:51:17 +00:00
|
|
|
}
|
2012-05-30 18:13:09 +00:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
2013-11-21 11:04:21 +00:00
|
|
|
* Reply to lastly received request message
|
2012-05-30 18:13:09 +00:00
|
|
|
*
|
2015-05-19 12:18:40 +00:00
|
|
|
* \param rcv_caps number of capabilities to accept when awaiting again
|
2013-11-21 10:35:33 +00:00
|
|
|
* \param await_request_msg wether the call shall await a request message
|
2013-10-17 11:51:17 +00:00
|
|
|
*
|
2013-11-21 11:04:21 +00:00
|
|
|
* \retval 0 await_request_msg == 0 or request-message receipt succeeded
|
|
|
|
* \retval -1 await_request_msg == 1 and request-message receipt failed
|
|
|
|
*
|
|
|
|
* If the call returns successful and await_request_msg == 1, the received
|
|
|
|
* message is located at the base of the callers userland thread-context.
|
2012-05-30 18:13:09 +00:00
|
|
|
*/
|
2015-05-19 12:18:40 +00:00
|
|
|
inline int send_reply_msg(unsigned rcv_caps, bool const await_request_msg)
|
2013-10-17 11:51:17 +00:00
|
|
|
{
|
2021-12-02 10:21:14 +00:00
|
|
|
return (int)call(call_id_send_reply_msg(), rcv_caps, await_request_msg);
|
2013-09-18 10:57:01 +00:00
|
|
|
}
|
|
|
|
|
2012-05-30 18:13:09 +00:00
|
|
|
|
|
|
|
/**
|
2013-11-27 23:45:48 +00:00
|
|
|
* Print a char c to the kernels serial ouput
|
|
|
|
*
|
|
|
|
* If c is set to 0 the kernel prints a table of all threads and their
|
|
|
|
* current activities to the serial output.
|
2012-05-30 18:13:09 +00:00
|
|
|
*/
|
|
|
|
inline void print_char(char const c)
|
2013-11-14 12:29:47 +00:00
|
|
|
{
|
2014-03-15 00:26:53 +00:00
|
|
|
call(call_id_print_char(), c);
|
2012-05-30 18:13:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
2013-10-30 12:56:57 +00:00
|
|
|
* Await any context of a receiver and optionally ack a context before
|
2013-09-11 22:48:27 +00:00
|
|
|
*
|
2015-05-19 12:18:40 +00:00
|
|
|
* \param receiver_id capability id of the targeted signal receiver
|
2012-05-30 18:13:09 +00:00
|
|
|
*
|
2013-09-11 22:48:27 +00:00
|
|
|
* \retval 0 suceeded
|
|
|
|
* \retval -1 failed
|
2012-05-30 18:13:09 +00:00
|
|
|
*
|
2013-09-11 22:48:27 +00:00
|
|
|
* If this call returns 0, an instance of 'Signal::Data' is located at the
|
|
|
|
* base of the callers UTCB. Every occurence of a signal is provided
|
2013-10-30 12:56:57 +00:00
|
|
|
* through this function until it gets delivered through this function or
|
|
|
|
* context respectively receiver get destructed. If multiple threads
|
|
|
|
* listen at the same receiver, and/or multiple contexts of the receiver
|
|
|
|
* trigger simultanously, there is no assertion about wich thread
|
|
|
|
* receives, and from wich context. A context that delivered once doesn't
|
|
|
|
* deliver again unless its last delivery has been acknowledged via
|
|
|
|
* ack_signal.
|
|
|
|
*/
|
2015-05-19 12:18:40 +00:00
|
|
|
inline int await_signal(capid_t const receiver_id)
|
2013-09-11 22:48:27 +00:00
|
|
|
{
|
2021-12-02 10:21:14 +00:00
|
|
|
return (int)call(call_id_await_signal(), receiver_id);
|
2013-09-11 22:48:27 +00:00
|
|
|
}
|
2012-05-30 18:13:09 +00:00
|
|
|
|
2019-03-11 10:42:36 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Check for any pending signal of a context of a receiver the calling
|
|
|
|
* thread relates to
|
|
|
|
*
|
|
|
|
* \param receiver_id capability id of the targeted signal receiver
|
|
|
|
*
|
|
|
|
* \retval 0 suceeded
|
|
|
|
* \retval -1 failed
|
|
|
|
*
|
|
|
|
* If this call returns 0, an instance of 'Signal::Data' is located at the
|
|
|
|
* base of the callers UTCB.
|
|
|
|
*/
|
|
|
|
inline int pending_signal(capid_t const receiver_id)
|
|
|
|
{
|
2021-12-02 10:21:14 +00:00
|
|
|
return (int)call(call_id_pending_signal(), receiver_id);
|
2019-03-11 10:42:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2017-02-24 13:29:29 +00:00
|
|
|
/**
|
|
|
|
* Request to cancel the next signal blocking of a local thread
|
|
|
|
*
|
|
|
|
* \param thread_id capability id of the targeted thread
|
|
|
|
*
|
|
|
|
* Does not block. Targeted thread must be in the same PD as the caller.
|
|
|
|
* If the targeted thread is in a signal blocking, cancels the blocking
|
|
|
|
* directly. Otherwise, stores the request and avoids the next signal
|
|
|
|
* blocking of the targeted thread as if it was immediately cancelled.
|
|
|
|
* If the target thread already holds a request, further ones get ignored.
|
|
|
|
*/
|
|
|
|
inline void cancel_next_await_signal(capid_t const thread_id)
|
|
|
|
{
|
|
|
|
call(call_id_cancel_next_await_signal(), thread_id);
|
|
|
|
}
|
|
|
|
|
2012-05-30 18:13:09 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Trigger a specific signal context
|
|
|
|
*
|
2015-05-19 12:18:40 +00:00
|
|
|
* \param context capability id of the targeted signal context
|
2013-09-11 22:48:27 +00:00
|
|
|
* \param num how often the context shall be triggered by this call
|
|
|
|
*
|
|
|
|
* \retval 0 suceeded
|
|
|
|
* \retval -1 failed
|
2012-05-30 18:13:09 +00:00
|
|
|
*/
|
2015-05-19 12:18:40 +00:00
|
|
|
inline int submit_signal(capid_t const context, unsigned const num)
|
2013-09-11 22:48:27 +00:00
|
|
|
{
|
2021-12-02 10:21:14 +00:00
|
|
|
return (int)call(call_id_submit_signal(), context, num);
|
2013-09-11 22:48:27 +00:00
|
|
|
}
|
2012-10-02 12:27:32 +00:00
|
|
|
|
2013-11-14 12:29:47 +00:00
|
|
|
|
2013-02-18 12:58:09 +00:00
|
|
|
/**
|
2013-09-11 22:48:27 +00:00
|
|
|
* Acknowledge the processing of the last delivery of a signal context
|
2013-02-18 12:58:09 +00:00
|
|
|
*
|
2015-05-19 12:18:40 +00:00
|
|
|
* \param context capability id of the targeted signal context
|
2013-02-18 12:58:09 +00:00
|
|
|
*/
|
2015-05-19 12:18:40 +00:00
|
|
|
inline void ack_signal(capid_t const context)
|
2013-09-11 22:48:27 +00:00
|
|
|
{
|
2014-03-15 00:26:53 +00:00
|
|
|
call(call_id_ack_signal(), context);
|
2013-09-11 22:48:27 +00:00
|
|
|
}
|
2013-02-18 12:58:09 +00:00
|
|
|
|
2013-11-14 12:29:47 +00:00
|
|
|
|
2013-12-05 23:12:43 +00:00
|
|
|
/**
|
|
|
|
* Halt processing of a signal context synchronously
|
|
|
|
*
|
2015-05-19 12:18:40 +00:00
|
|
|
* \param context capability id of the targeted signal context
|
2013-12-05 23:12:43 +00:00
|
|
|
*
|
|
|
|
* \retval 0 suceeded
|
|
|
|
* \retval -1 failed
|
|
|
|
*/
|
2015-05-19 12:18:40 +00:00
|
|
|
inline int kill_signal_context(capid_t const context)
|
2013-12-05 23:12:43 +00:00
|
|
|
{
|
2021-12-02 10:21:14 +00:00
|
|
|
return (int)call(call_id_kill_signal_context(), context);
|
2013-11-14 12:29:47 +00:00
|
|
|
}
|
2015-05-19 12:18:40 +00:00
|
|
|
|
2015-12-01 13:50:14 +00:00
|
|
|
/**
|
|
|
|
* Acknowledge reception of a capability
|
|
|
|
*
|
|
|
|
* \param cap capability id to acknowledge
|
|
|
|
*/
|
|
|
|
inline void ack_cap(capid_t const cap)
|
|
|
|
{
|
|
|
|
call(call_id_ack_cap(), cap);
|
|
|
|
}
|
|
|
|
|
2015-05-19 12:18:40 +00:00
|
|
|
/**
|
|
|
|
* Delete a capability id
|
|
|
|
*
|
|
|
|
* \param cap capability id to delete
|
|
|
|
*/
|
|
|
|
inline void delete_cap(capid_t const cap)
|
|
|
|
{
|
|
|
|
call(call_id_delete_cap(), cap);
|
|
|
|
}
|
2020-10-09 08:33:44 +00:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Execute a virtual-machine (again)
|
|
|
|
*
|
|
|
|
* \param vm pointer to vm kernel object
|
|
|
|
*/
|
|
|
|
inline void run_vm(capid_t const cap)
|
|
|
|
{
|
|
|
|
call(call_id_run_vm(), cap);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Stop execution of a virtual-machine
|
|
|
|
*
|
|
|
|
* \param vm pointer to vm kernel object
|
|
|
|
*/
|
|
|
|
inline void pause_vm(capid_t const cap)
|
|
|
|
{
|
|
|
|
call(call_id_pause_vm(), cap);
|
|
|
|
}
|
2012-05-30 18:13:09 +00:00
|
|
|
}
|
|
|
|
|
2016-01-20 19:52:51 +00:00
|
|
|
#endif /* _INCLUDE__KERNEL__INTERFACE_H_ */
|