[PATCH 12/16] c-user: Split up signal manager

Sebastian Huber sebastian.huber at embedded-brains.de
Thu Aug 20 10:19:01 UTC 2020


This makes it easier to automatically generate parts of the manager
documentation in the future.

Update #3993.
---
 c-user/index.rst               |   2 +-
 c-user/signal/background.rst   | 112 ++++++++++++
 c-user/signal/directives.rst   | 126 +++++++++++++
 c-user/signal/index.rst        |  15 ++
 c-user/signal/introduction.rst |  13 ++
 c-user/signal/operations.rst   |  75 ++++++++
 c-user/signal_manager.rst      | 322 ---------------------------------
 7 files changed, 342 insertions(+), 323 deletions(-)
 create mode 100644 c-user/signal/background.rst
 create mode 100644 c-user/signal/directives.rst
 create mode 100644 c-user/signal/index.rst
 create mode 100644 c-user/signal/introduction.rst
 create mode 100644 c-user/signal/operations.rst
 delete mode 100644 c-user/signal_manager.rst

diff --git a/c-user/index.rst b/c-user/index.rst
index 8e50423..dd7527d 100644
--- a/c-user/index.rst
+++ b/c-user/index.rst
@@ -39,7 +39,7 @@ RTEMS Classic API Guide (|version|).
 	barrier/index
 	message/index
 	event/index
-	signal_manager
+	signal/index
 	part/index
 	region/index
 	dpmem/index
diff --git a/c-user/signal/background.rst b/c-user/signal/background.rst
new file mode 100644
index 0000000..5ba5eeb
--- /dev/null
+++ b/c-user/signal/background.rst
@@ -0,0 +1,112 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Background
+==========
+
+.. index:: asynchronous signal routine
+.. index:: ASR
+
+Signal Manager Definitions
+--------------------------
+
+The signal manager allows a task to optionally define an asynchronous signal
+routine (ASR).  An ASR is to a task what an ISR is to an application's set of
+tasks.  When the processor is interrupted, the execution of an application is
+also interrupted and an ISR is given control.  Similarly, when a signal is sent
+to a task, that task's execution path will be "interrupted" by the ASR.
+Sending a signal to a task has no effect on the receiving task's current
+execution state.
+
+.. index:: rtems_signal_set
+
+A signal flag is used by a task (or ISR) to inform another task of the
+occurrence of a significant situation.  Thirty-two signal flags are associated
+with each task.  A collection of one or more signals is referred to as a signal
+set.  The data type ``rtems_signal_set`` is used to manipulate signal sets.
+
+A signal set is posted when it is directed (or sent) to a task. A pending
+signal is a signal that has been sent to a task with a valid ASR, but has not
+been processed by that task's ASR.
+
+.. index:: ASR vs. ISR
+.. index:: ISR vs. ASR
+
+A Comparison of ASRs and ISRs
+-----------------------------
+
+The format of an ASR is similar to that of an ISR with the following
+exceptions:
+
+- ISRs are scheduled by the processor hardware.  ASRs are scheduled by RTEMS.
+
+- ISRs do not execute in the context of a task and may invoke only a subset of
+  directives.  ASRs execute in the context of a task and may execute any
+  directive.
+
+- When an ISR is invoked, it is passed the vector number as its argument.  When
+  an ASR is invoked, it is passed the signal set as its argument.
+
+- An ASR has a task mode which can be different from that of the task.  An ISR
+  does not execute as a task and, as a result, does not have a task mode.
+
+.. index:: signal set, building
+
+Building a Signal Set
+---------------------
+
+A signal set is built by a bitwise OR of the desired signals.  The set of valid
+signals is ``RTEMS_SIGNAL_0`` through ``RTEMS_SIGNAL_31``.  If a signal is not
+explicitly specified in the signal set, then it is not present.  Signal values
+are specifically designed to be mutually exclusive, therefore bitwise OR and
+addition operations are equivalent as long as each signal appears exactly once
+in the component list.
+
+This example demonstrates the signal parameter used when sending the signal set
+consisting of ``RTEMS_SIGNAL_6``, ``RTEMS_SIGNAL_15``, and ``RTEMS_SIGNAL_31``.
+The signal parameter provided to the ``rtems_signal_send`` directive should be
+``RTEMS_SIGNAL_6 | RTEMS_SIGNAL_15 | RTEMS_SIGNAL_31``.
+
+.. index:: ASR mode, building
+
+Building an ASR Mode
+--------------------
+
+In general, an ASR's mode is built by a bitwise OR of the desired mode
+components.  The set of valid mode components is the same as those allowed with
+the task_create and task_mode directives.  A complete list of mode options is
+provided in the following table:
+
+.. list-table::
+ :class: rtems-table
+
+ * - ``RTEMS_PREEMPT``
+   - is masked by ``RTEMS_PREEMPT_MASK`` and enables preemption
+ * - ``RTEMS_NO_PREEMPT``
+   - is masked by ``RTEMS_PREEMPT_MASK`` and disables preemption
+ * - ``RTEMS_NO_TIMESLICE``
+   - is masked by ``RTEMS_TIMESLICE_MASK`` and disables timeslicing
+ * - ``RTEMS_TIMESLICE``
+   - is masked by ``RTEMS_TIMESLICE_MASK`` and enables timeslicing
+ * - ``RTEMS_ASR``
+   - is masked by ``RTEMS_ASR_MASK`` and enables ASR processing
+ * - ``RTEMS_NO_ASR``
+   - is masked by ``RTEMS_ASR_MASK`` and disables ASR processing
+ * - ``RTEMS_INTERRUPT_LEVEL(0)``
+   - is masked by ``RTEMS_INTERRUPT_MASK`` and enables all interrupts
+ * - ``RTEMS_INTERRUPT_LEVEL(n)``
+   - is masked by ``RTEMS_INTERRUPT_MASK`` and sets interrupts level n
+
+Mode values are specifically designed to be mutually exclusive, therefore
+bitwise OR and addition operations are equivalent as long as each mode appears
+exactly once in the component list.  A mode component listed as a default is
+not required to appear in the mode list, although it is a good programming
+practice to specify default components.  If all defaults are desired, the mode
+``DEFAULT_MODES`` should be specified on this call.
+
+This example demonstrates the mode parameter used with the
+``rtems_signal_catch`` to establish an ASR which executes at interrupt level
+three and is non-preemptible.  The mode should be set to
+``RTEMS_INTERRUPT_LEVEL(3) | RTEMS_NO_PREEMPT`` to indicate the desired
+processor mode and interrupt level.
diff --git a/c-user/signal/directives.rst b/c-user/signal/directives.rst
new file mode 100644
index 0000000..2479681
--- /dev/null
+++ b/c-user/signal/directives.rst
@@ -0,0 +1,126 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Directives
+==========
+
+This section details the signal manager's directives.  A subsection is
+dedicated to each of this manager's directives and describes the calling
+sequence, related constants, usage, and status codes.
+
+.. raw:: latex
+
+   \clearpage
+
+.. index:: establish an ASR
+.. index:: install an ASR
+.. index:: rtems_signal_catch
+
+.. _rtems_signal_catch:
+
+SIGNAL_CATCH - Establish an ASR
+-------------------------------
+
+CALLING SEQUENCE:
+    .. code-block:: c
+
+        rtems_status_code rtems_signal_catch(
+            rtems_asr_entry  asr_handler,
+            rtems_mode       mode
+        );
+
+DIRECTIVE STATUS CODES:
+    .. list-table::
+     :class: rtems-table
+
+     * - ``RTEMS_SUCCESSFUL``
+       - always successful
+
+DESCRIPTION:
+    This directive establishes an asynchronous signal routine (ASR) for the
+    calling task.  The asr_handler parameter specifies the entry point of the
+    ASR.  If asr_handler is NULL, the ASR for the calling task is invalidated
+    and all pending signals are cleared.  Any signals sent to a task with an
+    invalid ASR are discarded.  The mode parameter specifies the execution mode
+    for the ASR.  This execution mode supersedes the task's execution mode
+    while the ASR is executing.
+
+NOTES:
+    This directive will not cause the calling task to be preempted.
+
+    The following task mode constants are defined by RTEMS:
+
+    .. list-table::
+     :class: rtems-table
+
+     * - ``RTEMS_PREEMPT``
+       - is masked by ``RTEMS_PREEMPT_MASK`` and enables preemption
+     * - ``RTEMS_NO_PREEMPT``
+       - is masked by ``RTEMS_PREEMPT_MASK`` and disables preemption
+     * - ``RTEMS_NO_TIMESLICE``
+       - is masked by ``RTEMS_TIMESLICE_MASK`` and disables timeslicing
+     * - ``RTEMS_TIMESLICE``
+       - is masked by ``RTEMS_TIMESLICE_MASK`` and enables timeslicing
+     * - ``RTEMS_ASR``
+       - is masked by ``RTEMS_ASR_MASK`` and enables ASR processing
+     * - ``RTEMS_NO_ASR``
+       - is masked by ``RTEMS_ASR_MASK`` and disables ASR processing
+     * - ``RTEMS_INTERRUPT_LEVEL(0)``
+       - is masked by ``RTEMS_INTERRUPT_MASK`` and enables all interrupts
+     * - ``RTEMS_INTERRUPT_LEVEL(n)``
+       - is masked by ``RTEMS_INTERRUPT_MASK`` and sets interrupts level n
+
+.. raw:: latex
+
+   \clearpage
+
+.. index:: send signal set
+.. index:: rtems_signal_send
+
+.. _rtems_signal_send:
+
+SIGNAL_SEND - Send signal set to a task
+---------------------------------------
+
+CALLING SEQUENCE:
+    .. code-block:: c
+
+        rtems_status_code rtems_signal_send(
+            rtems_id         id,
+            rtems_signal_set signal_set
+        );
+
+DIRECTIVE STATUS CODES:
+    .. list-table::
+     :class: rtems-table
+
+     * - ``RTEMS_SUCCESSFUL``
+       - signal sent successfully
+     * - ``RTEMS_INVALID_ID``
+       - task id invalid
+     * - ``RTEMS_INVALID_NUMBER``
+       - empty signal set
+     * - ``RTEMS_NOT_DEFINED``
+       - ASR invalid
+
+DESCRIPTION:
+    This directive sends a signal set to the task specified in id.  The
+    signal_set parameter contains the signal set to be sent to the task.
+
+    If a caller sends a signal set to a task with an invalid ASR, then an error
+    code is returned to the caller.  If a caller sends a signal set to a task
+    whose ASR is valid but disabled, then the signal set will be caught and
+    left pending for the ASR to process when it is enabled. If a caller sends a
+    signal set to a task with an ASR that is both valid and enabled, then the
+    signal set is caught and the ASR will execute the next time the task is
+    dispatched to run.
+
+NOTES:
+    Sending a signal set to a task has no effect on that task's state.  If a
+    signal set is sent to a blocked task, then the task will remain blocked and
+    the signals will be processed when the task becomes the running task.
+
+    Sending a signal set to a global task which does not reside on the local
+    node will generate a request telling the remote node to send the signal set
+    to the specified task.
diff --git a/c-user/signal/index.rst b/c-user/signal/index.rst
new file mode 100644
index 0000000..ad28b9f
--- /dev/null
+++ b/c-user/signal/index.rst
@@ -0,0 +1,15 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+
+.. index:: signals
+
+Signal Manager
+**************
+
+.. toctree::
+
+    introduction
+    background
+    operations
+    directives
diff --git a/c-user/signal/introduction.rst b/c-user/signal/introduction.rst
new file mode 100644
index 0000000..292db52
--- /dev/null
+++ b/c-user/signal/introduction.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Introduction
+============
+
+The signal manager provides the capabilities required for asynchronous
+communication.  The directives provided by the signal manager are:
+
+- :ref:`rtems_signal_catch`
+
+- :ref:`rtems_signal_send`
diff --git a/c-user/signal/operations.rst b/c-user/signal/operations.rst
new file mode 100644
index 0000000..967b35f
--- /dev/null
+++ b/c-user/signal/operations.rst
@@ -0,0 +1,75 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+
+Operations
+==========
+
+Establishing an ASR
+-------------------
+
+The ``rtems_signal_catch`` directive establishes an ASR for the calling task.
+The address of the ASR and its execution mode are specified to this directive.
+The ASR's mode is distinct from the task's mode.  For example, the task may
+allow preemption, while that task's ASR may have preemption disabled.  Until a
+task calls ``rtems_signal_catch`` the first time, its ASR is invalid, and no
+signal sets can be sent to the task.
+
+A task may invalidate its ASR and discard all pending signals by calling
+``rtems_signal_catch`` with a value of NULL for the ASR's address.  When a
+task's ASR is invalid, new signal sets sent to this task are discarded.
+
+A task may disable ASR processing (``RTEMS_NO_ASR``) via the task_mode
+directive.  When a task's ASR is disabled, the signals sent to it are left
+pending to be processed later when the ASR is enabled.
+
+Any directive that can be called from a task can also be called from an ASR.  A
+task is only allowed one active ASR.  Thus, each call to ``rtems_signal_catch``
+replaces the previous one.
+
+Normally, signal processing is disabled for the ASR's execution mode, but if
+signal processing is enabled for the ASR, the ASR must be reentrant.
+
+Sending a Signal Set
+--------------------
+
+The ``rtems_signal_send`` directive allows both tasks and ISRs to send signals
+to a target task.  The target task and a set of signals are specified to the
+``rtems_signal_send`` directive.  The sending of a signal to a task has no
+effect on the execution state of that task.  If the task is not the currently
+running task, then the signals are left pending and processed by the task's ASR
+the next time the task is dispatched to run.  The ASR is executed immediately
+before the task is dispatched.  If the currently running task sends a signal to
+itself or is sent a signal from an ISR, its ASR is immediately dispatched to
+run provided signal processing is enabled.
+
+If an ASR with signals enabled is preempted by another task or an ISR and a new
+signal set is sent, then a new copy of the ASR will be invoked, nesting the
+preempted ASR.  Upon completion of processing the new signal set, control will
+return to the preempted ASR.  In this situation, the ASR must be reentrant.
+
+Like events, identical signals sent to a task are not queued.  In other words,
+sending the same signal multiple times to a task (without any intermediate
+signal processing occurring for the task), has the same result as sending that
+signal to that task once.
+
+.. index:: rtems_asr
+
+Processing an ASR
+-----------------
+
+Asynchronous signals were designed to provide the capability to generate
+software interrupts.  The processing of software interrupts parallels that of
+hardware interrupts.  As a result, the differences between the formats of ASRs
+and ISRs is limited to the meaning of the single argument passed to an ASR.
+The ASR should have the following calling sequence and adhere to C calling
+conventions:
+
+.. code-block:: c
+
+    rtems_asr user_routine(
+        rtems_signal_set signals
+    );
+
+When the ASR returns to RTEMS the mode and execution path of the interrupted
+task (or ASR) is restored to the context prior to entering the ASR.
diff --git a/c-user/signal_manager.rst b/c-user/signal_manager.rst
deleted file mode 100644
index 8cf1101..0000000
--- a/c-user/signal_manager.rst
+++ /dev/null
@@ -1,322 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-4.0
-
-.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
-
-.. index:: signals
-
-Signal Manager
-**************
-
-Introduction
-============
-
-The signal manager provides the capabilities required for asynchronous
-communication.  The directives provided by the signal manager are:
-
-- rtems_signal_catch_ - Establish an ASR
-
-- rtems_signal_send_ - Send signal set to a task
-
-Background
-==========
-
-.. index:: asynchronous signal routine
-.. index:: ASR
-
-Signal Manager Definitions
---------------------------
-
-The signal manager allows a task to optionally define an asynchronous signal
-routine (ASR).  An ASR is to a task what an ISR is to an application's set of
-tasks.  When the processor is interrupted, the execution of an application is
-also interrupted and an ISR is given control.  Similarly, when a signal is sent
-to a task, that task's execution path will be "interrupted" by the ASR.
-Sending a signal to a task has no effect on the receiving task's current
-execution state.
-
-.. index:: rtems_signal_set
-
-A signal flag is used by a task (or ISR) to inform another task of the
-occurrence of a significant situation.  Thirty-two signal flags are associated
-with each task.  A collection of one or more signals is referred to as a signal
-set.  The data type ``rtems_signal_set`` is used to manipulate signal sets.
-
-A signal set is posted when it is directed (or sent) to a task. A pending
-signal is a signal that has been sent to a task with a valid ASR, but has not
-been processed by that task's ASR.
-
-.. index:: ASR vs. ISR
-.. index:: ISR vs. ASR
-
-A Comparison of ASRs and ISRs
------------------------------
-
-The format of an ASR is similar to that of an ISR with the following
-exceptions:
-
-- ISRs are scheduled by the processor hardware.  ASRs are scheduled by RTEMS.
-
-- ISRs do not execute in the context of a task and may invoke only a subset of
-  directives.  ASRs execute in the context of a task and may execute any
-  directive.
-
-- When an ISR is invoked, it is passed the vector number as its argument.  When
-  an ASR is invoked, it is passed the signal set as its argument.
-
-- An ASR has a task mode which can be different from that of the task.  An ISR
-  does not execute as a task and, as a result, does not have a task mode.
-
-.. index:: signal set, building
-
-Building a Signal Set
----------------------
-
-A signal set is built by a bitwise OR of the desired signals.  The set of valid
-signals is ``RTEMS_SIGNAL_0`` through ``RTEMS_SIGNAL_31``.  If a signal is not
-explicitly specified in the signal set, then it is not present.  Signal values
-are specifically designed to be mutually exclusive, therefore bitwise OR and
-addition operations are equivalent as long as each signal appears exactly once
-in the component list.
-
-This example demonstrates the signal parameter used when sending the signal set
-consisting of ``RTEMS_SIGNAL_6``, ``RTEMS_SIGNAL_15``, and ``RTEMS_SIGNAL_31``.
-The signal parameter provided to the ``rtems_signal_send`` directive should be
-``RTEMS_SIGNAL_6 | RTEMS_SIGNAL_15 | RTEMS_SIGNAL_31``.
-
-.. index:: ASR mode, building
-
-Building an ASR Mode
---------------------
-
-In general, an ASR's mode is built by a bitwise OR of the desired mode
-components.  The set of valid mode components is the same as those allowed with
-the task_create and task_mode directives.  A complete list of mode options is
-provided in the following table:
-
-.. list-table::
- :class: rtems-table
-
- * - ``RTEMS_PREEMPT``
-   - is masked by ``RTEMS_PREEMPT_MASK`` and enables preemption
- * - ``RTEMS_NO_PREEMPT``
-   - is masked by ``RTEMS_PREEMPT_MASK`` and disables preemption
- * - ``RTEMS_NO_TIMESLICE``
-   - is masked by ``RTEMS_TIMESLICE_MASK`` and disables timeslicing
- * - ``RTEMS_TIMESLICE``
-   - is masked by ``RTEMS_TIMESLICE_MASK`` and enables timeslicing
- * - ``RTEMS_ASR``
-   - is masked by ``RTEMS_ASR_MASK`` and enables ASR processing
- * - ``RTEMS_NO_ASR``
-   - is masked by ``RTEMS_ASR_MASK`` and disables ASR processing
- * - ``RTEMS_INTERRUPT_LEVEL(0)``
-   - is masked by ``RTEMS_INTERRUPT_MASK`` and enables all interrupts
- * - ``RTEMS_INTERRUPT_LEVEL(n)``
-   - is masked by ``RTEMS_INTERRUPT_MASK`` and sets interrupts level n
-
-Mode values are specifically designed to be mutually exclusive, therefore
-bitwise OR and addition operations are equivalent as long as each mode appears
-exactly once in the component list.  A mode component listed as a default is
-not required to appear in the mode list, although it is a good programming
-practice to specify default components.  If all defaults are desired, the mode
-``DEFAULT_MODES`` should be specified on this call.
-
-This example demonstrates the mode parameter used with the
-``rtems_signal_catch`` to establish an ASR which executes at interrupt level
-three and is non-preemptible.  The mode should be set to
-``RTEMS_INTERRUPT_LEVEL(3) | RTEMS_NO_PREEMPT`` to indicate the desired
-processor mode and interrupt level.
-
-Operations
-==========
-
-Establishing an ASR
--------------------
-
-The ``rtems_signal_catch`` directive establishes an ASR for the calling task.
-The address of the ASR and its execution mode are specified to this directive.
-The ASR's mode is distinct from the task's mode.  For example, the task may
-allow preemption, while that task's ASR may have preemption disabled.  Until a
-task calls ``rtems_signal_catch`` the first time, its ASR is invalid, and no
-signal sets can be sent to the task.
-
-A task may invalidate its ASR and discard all pending signals by calling
-``rtems_signal_catch`` with a value of NULL for the ASR's address.  When a
-task's ASR is invalid, new signal sets sent to this task are discarded.
-
-A task may disable ASR processing (``RTEMS_NO_ASR``) via the task_mode
-directive.  When a task's ASR is disabled, the signals sent to it are left
-pending to be processed later when the ASR is enabled.
-
-Any directive that can be called from a task can also be called from an ASR.  A
-task is only allowed one active ASR.  Thus, each call to ``rtems_signal_catch``
-replaces the previous one.
-
-Normally, signal processing is disabled for the ASR's execution mode, but if
-signal processing is enabled for the ASR, the ASR must be reentrant.
-
-Sending a Signal Set
---------------------
-
-The ``rtems_signal_send`` directive allows both tasks and ISRs to send signals
-to a target task.  The target task and a set of signals are specified to the
-``rtems_signal_send`` directive.  The sending of a signal to a task has no
-effect on the execution state of that task.  If the task is not the currently
-running task, then the signals are left pending and processed by the task's ASR
-the next time the task is dispatched to run.  The ASR is executed immediately
-before the task is dispatched.  If the currently running task sends a signal to
-itself or is sent a signal from an ISR, its ASR is immediately dispatched to
-run provided signal processing is enabled.
-
-If an ASR with signals enabled is preempted by another task or an ISR and a new
-signal set is sent, then a new copy of the ASR will be invoked, nesting the
-preempted ASR.  Upon completion of processing the new signal set, control will
-return to the preempted ASR.  In this situation, the ASR must be reentrant.
-
-Like events, identical signals sent to a task are not queued.  In other words,
-sending the same signal multiple times to a task (without any intermediate
-signal processing occurring for the task), has the same result as sending that
-signal to that task once.
-
-.. index:: rtems_asr
-
-Processing an ASR
------------------
-
-Asynchronous signals were designed to provide the capability to generate
-software interrupts.  The processing of software interrupts parallels that of
-hardware interrupts.  As a result, the differences between the formats of ASRs
-and ISRs is limited to the meaning of the single argument passed to an ASR.
-The ASR should have the following calling sequence and adhere to C calling
-conventions:
-
-.. code-block:: c
-
-    rtems_asr user_routine(
-        rtems_signal_set signals
-    );
-
-When the ASR returns to RTEMS the mode and execution path of the interrupted
-task (or ASR) is restored to the context prior to entering the ASR.
-
-Directives
-==========
-
-This section details the signal manager's directives.  A subsection is
-dedicated to each of this manager's directives and describes the calling
-sequence, related constants, usage, and status codes.
-
-.. raw:: latex
-
-   \clearpage
-
-.. index:: establish an ASR
-.. index:: install an ASR
-.. index:: rtems_signal_catch
-
-.. _rtems_signal_catch:
-
-SIGNAL_CATCH - Establish an ASR
--------------------------------
-
-CALLING SEQUENCE:
-    .. code-block:: c
-
-        rtems_status_code rtems_signal_catch(
-            rtems_asr_entry  asr_handler,
-            rtems_mode       mode
-        );
-
-DIRECTIVE STATUS CODES:
-    .. list-table::
-     :class: rtems-table
-
-     * - ``RTEMS_SUCCESSFUL``
-       - always successful
-
-DESCRIPTION:
-    This directive establishes an asynchronous signal routine (ASR) for the
-    calling task.  The asr_handler parameter specifies the entry point of the
-    ASR.  If asr_handler is NULL, the ASR for the calling task is invalidated
-    and all pending signals are cleared.  Any signals sent to a task with an
-    invalid ASR are discarded.  The mode parameter specifies the execution mode
-    for the ASR.  This execution mode supersedes the task's execution mode
-    while the ASR is executing.
-
-NOTES:
-    This directive will not cause the calling task to be preempted.
-
-    The following task mode constants are defined by RTEMS:
-
-    .. list-table::
-     :class: rtems-table
-
-     * - ``RTEMS_PREEMPT``
-       - is masked by ``RTEMS_PREEMPT_MASK`` and enables preemption
-     * - ``RTEMS_NO_PREEMPT``
-       - is masked by ``RTEMS_PREEMPT_MASK`` and disables preemption
-     * - ``RTEMS_NO_TIMESLICE``
-       - is masked by ``RTEMS_TIMESLICE_MASK`` and disables timeslicing
-     * - ``RTEMS_TIMESLICE``
-       - is masked by ``RTEMS_TIMESLICE_MASK`` and enables timeslicing
-     * - ``RTEMS_ASR``
-       - is masked by ``RTEMS_ASR_MASK`` and enables ASR processing
-     * - ``RTEMS_NO_ASR``
-       - is masked by ``RTEMS_ASR_MASK`` and disables ASR processing
-     * - ``RTEMS_INTERRUPT_LEVEL(0)``
-       - is masked by ``RTEMS_INTERRUPT_MASK`` and enables all interrupts
-     * - ``RTEMS_INTERRUPT_LEVEL(n)``
-       - is masked by ``RTEMS_INTERRUPT_MASK`` and sets interrupts level n
-
-.. raw:: latex
-
-   \clearpage
-
-.. index:: send signal set
-.. index:: rtems_signal_send
-
-.. _rtems_signal_send:
-
-SIGNAL_SEND - Send signal set to a task
----------------------------------------
-
-CALLING SEQUENCE:
-    .. code-block:: c
-
-        rtems_status_code rtems_signal_send(
-            rtems_id         id,
-            rtems_signal_set signal_set
-        );
-
-DIRECTIVE STATUS CODES:
-    .. list-table::
-     :class: rtems-table
-
-     * - ``RTEMS_SUCCESSFUL``
-       - signal sent successfully
-     * - ``RTEMS_INVALID_ID``
-       - task id invalid
-     * - ``RTEMS_INVALID_NUMBER``
-       - empty signal set
-     * - ``RTEMS_NOT_DEFINED``
-       - ASR invalid
-
-DESCRIPTION:
-    This directive sends a signal set to the task specified in id.  The
-    signal_set parameter contains the signal set to be sent to the task.
-
-    If a caller sends a signal set to a task with an invalid ASR, then an error
-    code is returned to the caller.  If a caller sends a signal set to a task
-    whose ASR is valid but disabled, then the signal set will be caught and
-    left pending for the ASR to process when it is enabled. If a caller sends a
-    signal set to a task with an ASR that is both valid and enabled, then the
-    signal set is caught and the ASR will execute the next time the task is
-    dispatched to run.
-
-NOTES:
-    Sending a signal set to a task has no effect on that task's state.  If a
-    signal set is sent to a blocked task, then the task will remain blocked and
-    the signals will be processed when the task becomes the running task.
-
-    Sending a signal set to a global task which does not reside on the local
-    node will generate a request telling the remote node to send the signal set
-    to the specified task.
-- 
2.26.2



More information about the devel mailing list