doc: fix :option: x-refs to squash doc generation warnings

Move to use :option:`CONFIG_XYZ` vs :option:`XYZ` to generate propert
links and avoid warnings about unexistant targets.

Change-Id: I4b46041f25e538462b123ccc8337f733033cc0e7
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
This commit is contained in:
Inaky Perez-Gonzalez 2016-06-13 17:36:51 -07:00 committed by Anas Nashif
commit 2e99832616
10 changed files with 59 additions and 52 deletions

View file

@ -44,7 +44,7 @@ Usage
Configuring Custom Data Support
===============================
Use the :option:`THREAD_CUSTOM_DATA` configuration option
Use the :option:`CONFIG_THREAD_CUSTOM_DATA` configuration option
to enable support for thread custom data. By default, custom data
support is disabled.
@ -98,4 +98,4 @@ The following kernel execution context APIs are common to both
Writes custom data for currently executing task or fiber.
:c:func:`sys_thread_custom_data_get()`
Reads custom data for currently executing task or fiber.
Reads custom data for currently executing task or fiber.

View file

@ -122,17 +122,17 @@ Usage
Configuring Floating Point Services
===================================
To configure unshared FP registers mode, enable the :option:`FLOAT`
configuration option and leave the :option:`FP_SHARING` configuration option
To configure unshared FP registers mode, enable the :option:`CONFIG_FLOAT`
configuration option and leave the :option:`CONFIG_FP_SHARING` configuration option
disabled.
To configure shared FP registers mode, enable both the :option:`FLOAT`
configuration option and the :option:`FP_SHARING` configuration option.
To configure shared FP registers mode, enable both the :option:`CONFIG_FLOAT`
configuration option and the :option:`CONFIG_FP_SHARING` configuration option.
Also, ensure that any task that uses the floating point registers has
sufficient added stack space for saving floating point register values
during context switches, as described above.
Use the :option:`SSE` configuration option to enable support for
Use the :option:`CONFIG_SSE` configuration option to enable support for
SSEx instructions.

View file

@ -50,7 +50,7 @@ Usage
Configuring the Kernel Clocks
=============================
Use the :option:`SYS_CLOCK_TICKS_PER_SEC` configuration option
Use the :option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` configuration option
to specify how many ticks occur every second. Setting this value
to zero disables all system clock and hardware clock capabilities.

View file

@ -39,9 +39,9 @@ higher-priority fibers, such as time-sensitive device driver or
application fibers.
Both the fiber's stack size and scheduling priority can be configured
with the :option:`MICROKERNEL_SERVER_STACK_SIZE` and
:option:`MICROKERNEL_SERVER_PRIORITY` configuration options,
with the :option:`CONFIG_MICROKERNEL_SERVER_STACK_SIZE` and
:option:`CONFIG_MICROKERNEL_SERVER_PRIORITY` configuration options,
respectively.
See also :ref:`microkernel_server`.
See also :ref:`microkernel_server`.

View file

@ -44,9 +44,9 @@ its task priority to the priority it had before locking that mutex.
.. note::
The :option:`PRIORITY_CEILING` configuration option limits how high
the kernel can raise a task's priority due to priority inheritance.
The default value of 0 permits unlimited elevation.
The :option:`CONFIG_PRIORITY_CEILING` configuration option limits
how high the kernel can raise a task's priority due to priority
inheritance. The default value of 0 permits unlimited elevation.
When two or more tasks wait on a mutex held by a lower priority task, the
kernel adjusts the owning task's priority each time a task begins waiting

View file

@ -95,12 +95,14 @@ A task whose state has no factors that prevent its execution is said to be
Task Priorities
---------------
A microkernel application can be configured to support any number of task
priority levels using the :option:`NUM_TASK_PRIORITIES` configuration option.
A microkernel application can be configured to support any number of
task priority levels using the :option:`CONFIG_NUM_TASK_PRIORITIES`
configuration option.
An application task can have any priority from 0 (highest priority) down to
:option:`NUM_TASK_PRIORITIES`-2. The lowest priority level,
:option:`NUM_TASK_PRIORITIES`-1, is reserved for the microkernel's idle task.
An application task can have any priority from 0 (highest priority)
down to :option:`CONFIG_NUM_TASK_PRIORITIES`\-2. The lowest priority
level, :option:`CONFIG_NUM_TASK_PRIORITIES`\-1, is reserved for the
microkernel's idle task.
A task's original priority can be altered up or down after the task has been
started.
@ -140,10 +142,11 @@ The microkernel's scheduler supports an optional time slicing capability
that prevents a task from monopolizing the CPU when other tasks of the
same priority are ready to execute.
The scheduler divides time into a series of *time slices*, where slices
are measured in system clock ticks. The time slice size is specified with
the :option:`TIMESLICE_SIZE` configuration option, but this size can also
be changed dynamically, while the application is running.
The scheduler divides time into a series of *time slices*, where
slices are measured in system clock ticks. The time slice size is
specified with the :option:`CONFIG_TIMESLICE_SIZE` configuration
option, but this size can also be changed dynamically, while the
application is running.
At the end of every time slice, the scheduler implicitly invokes
:c:func:`task_yield()` on behalf of the current task; this gives
@ -154,10 +157,10 @@ tasks to execute. If no tasks of equal priority are ready to execute,
the current task remains the current task, and it continues to execute.
Tasks with a priority higher than that specified by the
:option:`TIMESLICE_PRIORITY` configuration option are exempt from time
slicing, and are never preempted by a task of equal priority. This
capability allows an application to use time slicing only for lower
priority tasks that are less time-sensitive.
:option:`CONFIG_TIMESLICE_PRIORITY` configuration option are exempt
from time slicing, and are never preempted by a task of equal
priority. This capability allows an application to use time slicing
only for lower priority tasks that are less time-sensitive.
.. note::
The microkernel's time slicing algorithm does *not* ensure that a set
@ -534,4 +537,4 @@ APIs Affecting Multiple Tasks
Resumes execution of all tasks in the specified task groups.
:c:func:`task_group_abort()`
Aborts execution of all tasks in the specified task groups.
Aborts execution of all tasks in the specified task groups.

View file

@ -79,10 +79,10 @@ Usage
Configuring Microkernel Timers
==============================
Set the :option:`NUM_TIMER_PACKETS` configuration option to specify the
number of timer-related command packets available in the application. This
value should be **equal to** or **greater than** the sum of the following
quantities:
Set the :option:`CONFIG_NUM_TIMER_PACKETS` configuration option to
specify the number of timer-related command packets available in the
application. This value should be **equal to** or **greater than** the
sum of the following quantities:
* The number of microkernel timers.
* The number of tasks.

View file

@ -65,9 +65,9 @@ This function is used as the background task's entry point function. If a
nanokernel application does not need to perform any task-level processing,
:code:`main()` can simply do an immediate return.
The :option:`MAIN_STACK_SIZE` configuration option specifies the size,
in bytes, of the memory region used for the background task's stack
and for other execution context information.
The :option:`CONFIG_MAIN_STACK_SIZE` configuration option specifies
the size, in bytes, of the memory region used for the background
task's stack and for other execution context information.
APIs
****

View file

@ -128,14 +128,16 @@ parameter.
* Using some architecture defined mechanism, the parameter value is forced in
the stub. This is commonly found in X86-based architectures.
* The parameters to the ISR are inserted and tracked via a separate table
requiring the architecture to discover at runtime which interrupt is
executing. A common interrupt handler demuxer is installed for all entries of
the real interrupt vector table, which then fetches the device's ISR and
parameter from the separate table. This approach is commonly used in the ARC
and ARM architectures via the :option:`SW_ISR_TABLE` implementation. You can find
examples of the stubs by looking at _IntEnt in x86, _IntExit in x86 and ARM,
:code:`_isr_wrapper()` in ARM, or the full implementation description for ARC in
* The parameters to the ISR are inserted and tracked via a separate
table requiring the architecture to discover at runtime which
interrupt is executing. A common interrupt handler demuxer is
installed for all entries of the real interrupt vector table, which
then fetches the device's ISR and parameter from the separate
table. This approach is commonly used in the ARC and ARM
architectures via the :option:`CONFIG_SW_ISR_TABLE`
implementation. You can find examples of the stubs by looking at
_IntEnt in x86, _IntExit in x86 and ARM, :code:`_isr_wrapper()` in
ARM, or the full implementation description for ARC in
:file:`arch/arc/core/isr_wrapper.S`.
Each architecture also has to implement primitives for interrupt control:
@ -304,10 +306,10 @@ mode if the thread triggered a fatal exception, but not if the thread
gracefully exits its entry point function.
This means implementing an architecture-specific version of
:c:func:`fiber_abort` and :code:`_TaskAbort`, and setting the two Kconfig
options :option:`ARCH_HAS_TASK_ABORT` and :option:`ARCH_HAS_NANO_FIBER_ABORT`
as needed for the architecture (e.g. see
:file:`arch/arm//core/cortex_m/Kconfig`).
:c:func:`fiber_abort` and :code:`_TaskAbort`, and setting the two
Kconfig options :option:`CONFIG_ARCH_HAS_TASK_ABORT` and
:option:`CONFIG_ARCH_HAS_NANO_FIBER_ABORT` as needed for the
architecture (e.g. see :file:`arch/arm//core/cortex_m/Kconfig`).
Device Drivers
**************
@ -391,8 +393,9 @@ port, since it is so useful for debugging. It is a simple polling, output-only,
serial port driver on which to send the console (:code:`printk`,
:code:`printf`) output.
It is not required, and a RAM console (:option:`RAM_CONSOLE`) can be used to
send all output to a circular buffer that can be read by a debugger instead.
It is not required, and a RAM console (:option:`CONFIG_RAM_CONSOLE`)
can be used to send all output to a circular buffer that can be read
by a debugger instead.
Utility Libraries
*****************

View file

@ -15,9 +15,10 @@ The Kconfig files are distributed across the build directory tree. The files
are organized based on their common characteristics and on what new symbols
they add to the configuration menus. For example:
* The Kconfig file at the root directory contains the general configuration
options like :option:`ARCH` and :option:`KERNEL VERSION`. These symbols are
defined for and apply to the entire build system.
* The Kconfig file at the root directory contains the general
configuration options like :option:`CONFIG_ARCH` and
``CONFIG_KERNEL VERSION``. These symbols are defined for and
apply to the entire build system.
* The Kconfig file at the :file:`kernel` directory contains the general
configuration related to the micro- and the nanokernel.