doc: fix misspellings and hyphen use
fixed error introduced in application.rst (v1.8) along with a general spelling check pass including consistent spelling of "runtime" and hyphenated words with "pre-" Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
parent
1956f09590
commit
8c708fd049
9 changed files with 15 additions and 16 deletions
|
@ -307,8 +307,7 @@ An application's :file:`.conf` file defines its default kernel configuration.
|
|||
The settings in this file override or augment the board configuration settings.
|
||||
|
||||
The board configuration settings can be viewed
|
||||
LENGTHlWRONGEPHY
|
||||
_BASE/boards/ARCHITECTURE/BOARD/BOARD_defconfig`.
|
||||
in :file:`$ZEPHYR_BASE/boards/ARCHITECTURE/BOARD/BOARD_defconfig`.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
|
@ -132,7 +132,7 @@ Setting the Toolchain Options
|
|||
=============================
|
||||
|
||||
In the Zephyr kernel source tree we provide two configurations for
|
||||
both ARM and X86 that can be used to pre-select the options needed
|
||||
both ARM and X86 that can be used to preselect the options needed
|
||||
for building the toolchain.
|
||||
The configuration files can be found in :file:`${ZEPHYR_BASE}/scripts/cross_compiler/`.
|
||||
|
||||
|
|
|
@ -44,7 +44,7 @@ small-footprint OSes:
|
|||
to be defined at compile-time, which reduces code size and
|
||||
increases performance.
|
||||
|
||||
#. **Minimal error checking**. Provides minimal run-time error checking
|
||||
#. **Minimal error checking**. Provides minimal runtime error checking
|
||||
to reduce code size and increase performance. An optional error-checking
|
||||
infrastructure is provided to assist in debugging during application
|
||||
development.
|
||||
|
|
|
@ -112,7 +112,7 @@ Defining a Memory Pool
|
|||
A memory pool is defined using a variable of type :c:type:`struct k_mem_pool`.
|
||||
However, since a memory pool also requires a number of variable-size data
|
||||
structures to represent its block sets and the status of its quad-blocks,
|
||||
the kernel does not support the run-time definition of a memory pool.
|
||||
the kernel does not support the runtime definition of a memory pool.
|
||||
A memory pool can only be defined and initialized at compile time
|
||||
by calling :c:macro:`K_MEM_POOL_DEFINE`.
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ The kernel currently provides only a subset of C++ functionality. The
|
|||
following features are *not* supported:
|
||||
|
||||
* Dynamic object management with the **new** and **delete** operators
|
||||
* :abbr:`RTTI (run-time type information)`
|
||||
* :abbr:`RTTI (runtime type information)`
|
||||
* Exceptions
|
||||
* Static global object destruction
|
||||
|
||||
|
|
|
@ -98,17 +98,17 @@ to support the SSE registers, or as an FPU user if the SSE registers are
|
|||
not supported. If this would result in a thread that is an FPU user being
|
||||
tagged as an SSE user, or if the application wants to avoid the exception
|
||||
handling overhead involved in auto-tagging threads, it is possible to
|
||||
pre-tag a thread using one of the techniques listed below.
|
||||
pretag a thread using one of the techniques listed below.
|
||||
|
||||
* A statically-created x86 thread can be pre-tagged by passing the
|
||||
* A statically-created x86 thread can be pretagged by passing the
|
||||
:c:macro:`K_FP_REGS` or :c:macro:`K_SSE_REGS` option to
|
||||
:c:macro:`K_THREAD_DEFINE`.
|
||||
|
||||
* A dynamically-created x86 thread can be pre-tagged by passing the
|
||||
* A dynamically-created x86 thread can be pretagged by passing the
|
||||
:c:macro:`K_FP_REGS` or :c:macro:`K_SSE_REGS` option to
|
||||
:cpp:func:`k_thread_create()`.
|
||||
|
||||
* An already-created x86 thread can pre-tag itself once it has started
|
||||
* An already-created x86 thread can pretag itself once it has started
|
||||
by passing the :c:macro:`K_FP_REGS` or :c:macro:`K_SSE_REGS` option to
|
||||
:cpp:func:`k_float_enable()`.
|
||||
|
||||
|
|
|
@ -127,7 +127,7 @@ Implementation
|
|||
Defining a regular ISR
|
||||
======================
|
||||
|
||||
An ISR is defined at run-time by calling :c:macro:`IRQ_CONNECT`. It must
|
||||
An ISR is defined at runtime by calling :c:macro:`IRQ_CONNECT`. It must
|
||||
then be enabled by calling :cpp:func:`irq_enable()`.
|
||||
|
||||
.. important::
|
||||
|
|
|
@ -210,7 +210,7 @@ JIRA Related Items
|
|||
* :jira:`ZEP-2151` - Move Quark D2000 to device tree
|
||||
* :jira:`ZEP-2156` - Build warnings [-Wformat] with LLVM/icx (tests/kernel/sprintf)
|
||||
* :jira:`ZEP-2168` - Timers seem to be broken with TICKLESS_KERNEL on nRF51 (Cortex M0)
|
||||
* :jira:`ZEP-2171` - Move all board pinmux code from drivers/pinmux/stm32 to the corrosponding board/soc locations
|
||||
* :jira:`ZEP-2171` - Move all board pinmux code from drivers/pinmux/stm32 to the corresponding board/soc locations
|
||||
* :jira:`ZEP-2184` - Split data, bss, noinit sections into application and kernel areas
|
||||
* :jira:`ZEP-2188` - x86: Implement simple stack memory protection
|
||||
* :jira:`ZEP-2217` - schedule_api test fails on ARM with tickless kernel enabled
|
||||
|
|
|
@ -405,9 +405,9 @@ The quality assurance part encompasses the following criteria:
|
|||
possible.
|
||||
|
||||
- **Automation:** the review process and checks for coding rule
|
||||
adherence are a mandatory part of the pre-commit checks. To
|
||||
adherence are a mandatory part of the precommit checks. To
|
||||
ensure consistent application, they shall be automated as part of
|
||||
the pre-commit procedure. Prior to merging large pieces of code
|
||||
the precommit procedure. Prior to merging large pieces of code
|
||||
in from subsystems, in addition to review process and coding rule
|
||||
adherence, all static code analysis must have been run and issues
|
||||
resolved.
|
||||
|
@ -708,7 +708,7 @@ In general, the steps towards a certification or precertification
|
|||
protect the assets against exploits of vulnerabilities of the
|
||||
system. As a complete threat model includes the overall product
|
||||
including the hardware platform, this might be realized by a
|
||||
split model containing a pre-certified secure branch of Zephyr
|
||||
split model containing a precertified secure branch of Zephyr
|
||||
which the vendor could use to certify their Zephyr-enabled
|
||||
product.
|
||||
|
||||
|
@ -733,7 +733,7 @@ Certification Options
|
|||
For the security certification as such, the following options can be
|
||||
pursued:
|
||||
|
||||
1. **Abstract (pre-)certification of Zephyr as a pure software system:**
|
||||
1. **Abstract precertification of Zephyr as a pure software system:**
|
||||
this option requires assumptions on the underlying hardware
|
||||
platform and the final application running on top of Zephyr. If
|
||||
these assumptions are met by the hardware and the application, a
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue