The BlackBerry 10 OS microkernel
The QNX Neutrino RTOS implements the core POSIX features used in embedded realtime systems, along with the fundamental BlackBerry 10 OS message-passing services.The POSIX features that aren't implemented in the procnto microkernel (file and device I/O, for example) are provided by optional processes and shared libraries.
To determine the release version of the kernel on your system, use the uname -a command.
Successive microkernels from QNX Software Systems 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 BlackBerry 10 OS pulses into common data structures and code to manipulate those structures).
At its lowest level, the microkernel contains a few fundamental objects and the highly tuned routines that manipulate them. The OS is built from this foundation.
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.
The implementation of the BlackBerry 10 OS
Historically, the application pressure on QNX Software Systems' operating systems has been from both ends of the computing spectrum—from memory-limited embedded systems all the way up to high-end SMP (symmetrical multiprocessing) machines with gigabytes of physical memory. Accordingly, the design goals for BlackBerry 10 OS 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.
POSIX realtime and thread extensions
Since the BlackBerry 10 OS implements the majority of the realtime and thread services directly in the QNX Neutrino RTOS, 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. To accommodate this, the OS provides direct support for threads, but relies on its process manager portion to extend this functionality to processes containing multiple threads.
Note that many realtime executives and kernels provide only a nonmemory-protected threaded model, with no process model and/or protected memory model at all. Without a process model, full POSIX compliance cannot be achieved.
The QNX Neutrino RTOS has kernel calls to support the following:
- Message passing
- Interrupt handlers
- Mutual exclusion locks (mutexes)
- Condition variables (condvars)
The entire OS is built upon these calls. The OS is fully preemptible, even while passing messages between processes; it resumes the message pass where it left off before preemption.
The minimal complexity of the microkernel helps place an upper bound on the longest nonpreemptible 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 (for example, 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 shows the preemption details for the non-SMP kernel (x86 implementation).
Interrupts are disabled, or preemption is held off, for only very brief intervals (typically in the order of hundreds of nanoseconds).
Last modified: 2015-03-31