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
|
|
|
|
|
|
|
namespace Kernel
|
|
|
|
{
|
|
|
|
/**
|
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; }
|
|
|
|
constexpr Call_arg call_id_cancel_next_await_signal() { return 9; }
|
|
|
|
constexpr Call_arg call_id_ack_signal() { return 10; }
|
|
|
|
constexpr Call_arg call_id_print_char() { return 11; }
|
|
|
|
constexpr Call_arg call_id_update_data_region() { return 12; }
|
|
|
|
constexpr Call_arg call_id_update_instr_region() { return 13; }
|
|
|
|
constexpr Call_arg call_id_ack_cap() { return 14; }
|
|
|
|
constexpr Call_arg call_id_delete_cap() { return 15; }
|
|
|
|
constexpr Call_arg call_id_timeout() { return 16; }
|
|
|
|
constexpr Call_arg call_id_timeout_age_us() { return 17; }
|
|
|
|
constexpr Call_arg call_id_timeout_max_us() { return 18; }
|
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
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
inline int timeout(time_t const duration_us, capid_t const sigid)
|
|
|
|
{
|
|
|
|
return call(call_id_timeout(), duration_us, sigid);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Return time in microseconds since the caller installed its last timeout
|
|
|
|
*
|
|
|
|
* Must not be called if the installation is older than 'timeout_max_us'.
|
|
|
|
*/
|
|
|
|
inline time_t timeout_age_us()
|
|
|
|
{
|
|
|
|
return call(call_id_timeout_age_us());
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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()
|
|
|
|
{
|
|
|
|
return call(call_id_timeout_max_us());
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Globally apply writes to a data region in the current domain
|
|
|
|
*
|
|
|
|
* \param base base of the region within the current domain
|
|
|
|
* \param size size of the region
|
|
|
|
*/
|
|
|
|
inline void update_data_region(addr_t const base, size_t const size)
|
|
|
|
{
|
|
|
|
call(call_id_update_data_region(), (Call_arg)base, (Call_arg)size);
|
|
|
|
}
|
2012-05-30 18:13:09 +00:00
|
|
|
|
2014-04-07 14:18:43 +00:00
|
|
|
/**
|
|
|
|
* Globally apply writes to an instruction region in the current domain
|
|
|
|
*
|
|
|
|
* \param base base of the region within the current domain
|
|
|
|
* \param size size of the region
|
|
|
|
*/
|
|
|
|
inline void update_instr_region(addr_t const base, size_t const size)
|
|
|
|
{
|
|
|
|
call(call_id_update_instr_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
|
|
|
{
|
2015-05-19 12:18:40 +00:00
|
|
|
return 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
|
|
|
{
|
2015-05-19 12:18:40 +00:00
|
|
|
return 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
|
|
|
{
|
2015-05-19 12:18:40 +00:00
|
|
|
return 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
|
|
|
{
|
2015-03-17 14:41:47 +00:00
|
|
|
return call(call_id_await_signal(), receiver_id);
|
2013-09-11 22:48:27 +00:00
|
|
|
}
|
2012-05-30 18:13:09 +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
|
|
|
{
|
2014-03-15 00:26:53 +00:00
|
|
|
return 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
|
|
|
{
|
2014-03-15 00:26:53 +00:00
|
|
|
return 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);
|
|
|
|
}
|
2012-05-30 18:13:09 +00:00
|
|
|
}
|
|
|
|
|
2016-01-20 19:52:51 +00:00
|
|
|
#endif /* _INCLUDE__KERNEL__INTERFACE_H_ */
|