doc: remove kernel version 2 wording
Version 1 kernel (release 1.5 and earlier) is far enough from memory now to remove the "version 2" wording in the kernel documentation and just call it "the kernel". Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
parent
dc0fc57917
commit
9d4c2748db
2 changed files with 26 additions and 33 deletions
|
@ -1,7 +1,7 @@
|
|||
.. _kernel:
|
||||
|
||||
Zephyr Kernel Primer (version 2)
|
||||
################################
|
||||
Zephyr Kernel Primer
|
||||
####################
|
||||
|
||||
This document provides a general introduction of the Zephyr kernel's
|
||||
key capabilities and services. Additional details can be found by consulting
|
||||
|
|
|
@ -3,9 +3,11 @@
|
|||
Changes from Version 1 Kernel
|
||||
#############################
|
||||
|
||||
The version 2 kernel incorporates numerous changes
|
||||
that improve ease of use for developers.
|
||||
Some of the major benefits of these changes are:
|
||||
The current Zephyr kernel incorporates numerous changes from
|
||||
kernels found in the 1.5 and earlier releases, and improves
|
||||
ease of use for developers.
|
||||
|
||||
Some of the benefits of these changes are:
|
||||
|
||||
* elimination of separate microkernel and nanokernel build types,
|
||||
* elimination of the MDEF in microkernel-based applications,
|
||||
|
@ -14,21 +16,12 @@ Some of the major benefits of these changes are:
|
|||
* reducing memory footprint by merging duplicated services, and
|
||||
* improving performance by reducing context switching.
|
||||
|
||||
.. note::
|
||||
To ease the transition of existing applications and other Zephyr subsystems
|
||||
to the new kernel model, the revised kernel will continue to support
|
||||
the version 1 "legacy" APIs and MDEF for a limited period of time,
|
||||
after which support will be removed.
|
||||
|
||||
The changes introduced by the version 2 kernel are too numerous to fully
|
||||
describe here; readers are advised to consult the individual sections of the
|
||||
Kernel Primer to familiarize themselves with the way the version 2 kernel
|
||||
operates. However, the most significant changes are summarized below.
|
||||
The most significant changes are discussed below.
|
||||
|
||||
Application Design
|
||||
******************
|
||||
|
||||
The microkernel and nanokernel portions of Zephyr have been merged into
|
||||
The earlier microkernel and nanokernel portions of Zephyr have been merged into
|
||||
a single entity, which is simply referred to as "the kernel". Consequently,
|
||||
there is now only a single way to design and build Zephyr applications.
|
||||
|
||||
|
@ -39,16 +32,16 @@ setting it to a non-negative priority makes it a "preemptive thread",
|
|||
which operates in a task-like manner.
|
||||
|
||||
Kernel objects can now be used by both task-like threads and fiber-like
|
||||
threads. (The version 1 kernel did not permit fibers to use microkernel
|
||||
threads. (The previous kernel did not permit fibers to use microkernel
|
||||
objects, and could result in undesirable busy-waiting when nanokernel
|
||||
objects were used by tasks.)
|
||||
|
||||
Kernel objects now typically allow multiple threads to wait on a given
|
||||
object. (The version 1 kernel restricted waiting on certain types of
|
||||
object. (The previous kernel restricted waiting on certain types of
|
||||
kernel object to a single thread.)
|
||||
|
||||
Kernel object APIs now always execute in the context of the invoking thread.
|
||||
(The version 1 kernel required microkernel object APIs to context switch
|
||||
(The previous kernel required microkernel object APIs to context switch
|
||||
the thread to the microkernel server fiber, followed by another context
|
||||
switch back to the invoking thread.)
|
||||
|
||||
|
@ -64,12 +57,12 @@ Most kernel APIs have been renamed or have had changes to their arguments
|
|||
(or both) to make them more intuitive, and to improve consistency.
|
||||
The **k_** and **K_** prefixes are now used by most kernel APIs.
|
||||
|
||||
A version 1 kernel operation that can be invoked from a task, a fiber,
|
||||
A previous kernel operation that can be invoked from a task, a fiber,
|
||||
or an ISR using distinct APIs is now invoked from a thread or an ISR
|
||||
using a single common API.
|
||||
|
||||
Many kernel APIs now return 0 to indicate success and a non-zero error code
|
||||
to indicate the reason for failure. (The version 1 kernel supported only
|
||||
to indicate the reason for failure. (The previous kernel supported only
|
||||
two error codes, rather than an unlimited number of them.)
|
||||
|
||||
Threads
|
||||
|
@ -79,11 +72,11 @@ A task-like thread can now make itself temporarily non-preemptible
|
|||
by locking the kernel's scheduler (rather than by locking interrupts).
|
||||
|
||||
It is now possible to pass up to 3 arguments to a thread's entry point.
|
||||
(The version 1 kernel allowed 2 arguments to be passed to a fiber
|
||||
(The previous kernel allowed 2 arguments to be passed to a fiber
|
||||
and allowed no arguments to be passed to a task.)
|
||||
|
||||
It is now possible to delay the start of a statically-defined threads.
|
||||
(The version 1 kernel only permitted delaying of fibers spawned at run time.)
|
||||
(The previous kernel only permitted delaying of fibers spawned at run time.)
|
||||
|
||||
A task can no longer specify an "task abort handler" function
|
||||
that is invoked automatically when the task terminates or aborts.
|
||||
|
@ -93,7 +86,7 @@ of a set of related tasks by invoking a single kernel API.
|
|||
However, applications can provide their own APIs to achieve a similar effect.
|
||||
|
||||
The kernel now spawns both a "main thread" and an "idle thread" during
|
||||
startup. (The version 1 kernel spawned only a single thread.)
|
||||
startup. (The previous kernel spawned only a single thread.)
|
||||
|
||||
The kernel's main thread performs system initialization and then invokes
|
||||
:cpp:func:`main()`. If no :cpp:func:`main()` is defined by the application,
|
||||
|
@ -110,8 +103,8 @@ in system clock ticks. This change makes things more intuitive for most
|
|||
developers. However, the kernel still implements timeouts using the
|
||||
tick-based system clock.
|
||||
|
||||
The nanokernel timer and microkernel timer object types have been merged
|
||||
into a single type.
|
||||
The previous nanokernel timer and microkernel timer object types have beeni
|
||||
merged into a single type.
|
||||
|
||||
Memory Allocation
|
||||
*****************
|
||||
|
@ -130,7 +123,7 @@ from a heap data pool.
|
|||
Synchronization
|
||||
***************
|
||||
|
||||
The nanokernel semaphore and microkernel semaphore object types have been
|
||||
The prevous nanokernel semaphore and microkernel semaphore object types have been
|
||||
merged into a single type. The new type can now be used as a binary semaphore,
|
||||
as well as a counting semaphore.
|
||||
|
||||
|
@ -141,7 +134,7 @@ to wait on multiple semaphores must either test them individually in a
|
|||
non-blocking manner or use an additional mechanism, such as an event object,
|
||||
to signal the application that one of the semaphores is available.
|
||||
|
||||
The microkernel event object type is renamed to "alert" and is now presented as
|
||||
The previous microkernel event object type is renamed to "alert" and is now presented as
|
||||
a relative to Unix-style signalling. Due to improvements to the implementation
|
||||
of semaphores, alerts are now less efficient to use for basic synchronization
|
||||
than semaphores; consequently, alerts should now be reserved for scenarios
|
||||
|
@ -150,19 +143,19 @@ requiring the use of a callback function.
|
|||
Data Passing
|
||||
************
|
||||
|
||||
The microkernel FIFO object type has been renamed to "message queue",
|
||||
The previous microkernel FIFO object type has been renamed to "message queue",
|
||||
to avoid confusion with the nanokernel FIFO object type.
|
||||
|
||||
It is now possible to specify the alignment used by the data items
|
||||
stored in a message queue (aka microkernel FIFO).
|
||||
|
||||
The microkernel mailbox object type no longer supports the explicit message
|
||||
The previous microkernel mailbox object type no longer supports the explicit message
|
||||
priority concept. Messages are now implicitly ordered based on the priority
|
||||
of the sending thread.
|
||||
|
||||
The microkernel mailbox object type now supports the sending of asynchronous
|
||||
messages using a message buffer. (The version 1 kernel only supported
|
||||
The mailbox object type now supports sending asynchronous
|
||||
messages using a message buffer. (The previous kernel only supported
|
||||
asynchronous messages using a message block.)
|
||||
|
||||
It is now possible to specify the alignment used by a microkernel pipe object's
|
||||
It is now possible to specify the alignment used by a pipe object's
|
||||
buffer.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue