michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: remove kernel version 2 wording

Browse source 
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:
David B. Kinder 2017-05-04 14:49:43 -07:00 • committed by Anas Nashif
commit 9d4c2748db
2 changed files with 26 additions and 33 deletions
Download patch file Download diff file Expand all files Collapse all files

4
doc/kernel/kernel.rst
View file

@ -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

55
doc/kernel/overview/changes.rst
View file

@ -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.