Neutrino is a microkernel implementation of the core POSIX features used in embedded realtime systems, along with the fundamental QNX^® message-passing services. The POSIX features that aren't implemented in the microkernel (file and device I/O, for example) are provided by optional processes and shared libraries.

Successive QNX® microkernels have seen a reduction in the code required to implement a given kernel call. The object definitions at the lowest layer in the kernel code have become more specific, allowing greater code reuse (such as folding various forms of POSIX signals, realtime signals, and QNX® pulses into common data structures and code to manipulate those structures).

At its lowest level, Neutrino contains a few fundamental objects and the highly tuned routines that manipulate them. The Neutrino microkernel is built from this foundation.

The Neutrino microkernel.

Some developers have assumed that our microkernel is implemented entirely in assembly code for size or performance reasons. In fact, our implementation is coded primarily in C; size and performance goals are achieved through successively refined algorithms and data structures, rather than via assembly-level peep-hole optimizations.

Historically, the "application pressure" on QNX® has been from both ends of the computing spectrum - from memory-limited embedded systems all the way up to high-end SMP (Symmetrical Multi-Processing) machines with gigabytes of physical memory. Accordingly, the design goals for Neutrino accommodate both seemingly exclusive sets of functionality. Pursuing these goals is intended to extend the reach of systems well beyond what other OS implementations could address.

The "Holy Grail" of operating systems.

POSIX realtime and thread extensions

Since Neutrino implements the majority of the realtime and thread services directly in the microkernel, these services are available even without the presence of additional OS modules.

In addition, some of the profiles defined by POSIX suggest that these services be present without necessarily requiring a process model. In order to accommodate this, Neutrino provides direct support for threads, but relies on an add-on process manager to extend this functionality to processes containing multiple threads.

Note that many realtime executives and kernels provide only a non-memory-protected threaded model, with no process model and/or protected memory model at all. Without a process model, full POSIX compliance cannot be achieved.

Scalable for very small embedded systems

To target very small embedded systems, Neutrino goes a step further than earlier versions of QNX® by allowing even the process manager to be an optional component. When running without a process manager, Neutrino lacks the ability to create processes and has only limited, library-implemented pathname space management. As a result, a minimal Neutrino embedded system must boot with an initial code set and must not attempt to create processes during runtime (although additional threads can be created).

This is a reasonable tradeoff, since many embedded systems don't need to dynamically create processes; they boot with an initial code set and run "as is." Support for dynamic process creation would go unused in such systems.

Neutrino system process containing threads.

The Neutrino microkernel has kernel calls to support the following:

• threads
• message passing
• signals
• clocks
• timers
• interrupt handlers
• semaphores
• mutual exclusion locks (mutexes)
• condition variables (condvars)

The entire OS is built upon these calls. Neutrino is fully preemptable, even while passing messages between processes; it resumes the message pass where it left off before preemption.

The minimal complexity of the Neutrino microkernel helps place an upper bound on the longest non-preemptable code path through the kernel, while the small code size makes addressing complex multiprocessor issues a tractable problem. Services were chosen for inclusion in the microkernel on the basis of having a short execution path. Operations requiring significant work (e.g. process loading) were assigned to external processes/threads, where the effort to enter the context of that thread would be insignificant compared to the work done within the thread to service the request.

Rigorous application of this rule to dividing the functionality between the kernel and external processes destroys the myth that a microkernel OS must incur higher runtime overhead than a monolithic kernel OS. Given the work done between context switches (implicit in a message pass), and the very quick context-switch times that result from the simplified kernel, the time spent performing context switches becomes "lost in the noise" of the work done to service the requests communicated by the message passing between the processes that make up the OS.

The following diagram illustrates the kernel being preempted and interrupted through various stages of processing a message-pass request.

Neutrino preemption details for the non-SMP kernel (x86 implementation). The SMP version of the kernel has more opcodes.

Interrupts are disabled, or preemption is held off, for only very brief intervals.

<< Previous | Index | Next >>