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:

• elimination of separate microkernel and nanokernel build types,
• elimination of the MDEF in microkernel-based applications,
• simplifying and streamlining the kernel API,
• easing restrictions on the use of kernel objects,
• 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.

Application Design

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

The task and fiber context types have been merged into a single type, known as a “thread”. Setting a thread’s priority to a negative priority makes it a “cooperative thread”, which operates in a fiber-like manner; 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 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 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 thread to the microkernel server fiber, followed by another context switch back to the invoking thread.)

The MDEF has been eliminated. Consequently, all kernel objects are now defined directly in code.

Kernel APIs

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, 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 two error codes, rather than an unlimited number of them.)

Threads

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

A task can no longer specify an “task abort handler” function that is invoked automatically when the task terminates or aborts.

An application can no longer use “task groups” to alter the operation 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.)

The kernel’s main thread performs system initialization and then invokes main(). If no main() is defined by the application, the main thread terminates.

System initialization code can now perform blocking operations, during which time the kernel’s idle thread executes.

Timing

Most kernel APIs now specify timeout intervals in milliseconds, rather than 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.

Memory Allocation

The microkernel memory map object has been renamed to “memory slab”, to better reflect its management of equal-size memory blocks.

It is now possible to specify the alignment used by the memory blocks belonging to a memory slab or a memory pool.

It is now possible to define a memory pool directly in code.

It is now possible to allocate and free memory in a malloc()-like manner from a heap data pool.

Synchronization

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

An application can no longer use a “semaphore group” to allow a thread to wait on multiple semaphores simultaneously. Until the kernel incorporates a select() or poll() capability an application wishing 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 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 requiring the use of a callback function.

Data Passing

The 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 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 asynchronous messages using a message block.)

It is now possible to specify the alignment used by a microkernel pipe object’s buffer.