Although many new operating systems are said to be microkernels (or even nanokernels), the term may not mean very much without a clear definition.
Let's try to define the term. A microkernel OS is structured as a tiny kernel that provides the minimal services used by a team of optional cooperating processes, which in turn provide the higher-level OS functionality. The microkernel itself lacks file systems and many other services normally expected of an OS; those services are provided by optional processes.
The real goal in designing a microkernel OS is not simply to make it small. A microkernel OS embodies a fundamental change in the approach to delivering OS functionality. Modularity is the key, size is but a side effect. To call any kernel a microkernel simply because it happens to be small would miss the point entirely.
Since the IPC services provided by the microkernel are used to glue the OS itself together, the performance and flexibility of those services govern the performance of the resulting OS. With the exception of those IPC services, a microkernel is roughly comparable to a realtime executive, both in terms of the services provided and in their realtime performance.
The microkernel differs from an executive in how the IPC services are used to extend the functionality of the kernel with additional, service-providing processes. Since the OS is implemented as a team of cooperating processes managed by the microkernel, user-written processes can serve both as applications and as processes that extend the underlying OS functionality for industry-specific applications. The OS itself becomes open and easily extensible. Moreover, user-written extensions to the OS won't affect the fundamental reliability of the core OS.
A difficulty for many realtime executives implementing the POSIX 1003.1 standard is that their runtime environment is typically a single-process, multiple-threaded model, with unprotected memory between threads. Such an environment is only a subset of the multi-process model that POSIX assumes; it cannot support the fork() function. In contrast, BlackBerry 10 OS fully utilizes an MMU to deliver the complete POSIX process model in a protected environment.
As the following diagrams show, a true microkernel offers complete memory protection, not only for user applications, but also for OS components (device drivers, file systems, and so on.):
This diagram shows that conventional real time executives provide no memory protection:
This diagram shows that a monolithic OS provides no protection to system processes:
This diagram shows that a microkernel provides complete memory protection:
The OS as a team of processes
The BlackBerry 10 OS consists of a small microkernel managing a group of cooperating processes. As the following illustration shows, the structure looks more like a team than a hierarchy, as several players of equal rank interact with each other through the coordinating kernel.
BlackBerry 10 OS acts as a kind of software bus that lets you dynamically plug in/out OS modules whenever they're needed.
A true kernel
The kernel is the heart of any operating system. In some systems, the kernel comprises so many functions that for all intents and purposes it is the entire operating system! But our QNX Neutrino microkernel is truly a kernel. First of all, like the kernel of a realtime executive, it's very small. Secondly, it's dedicated to only a few fundamental services:
- Thread services via POSIX thread-creation primitives
- Signal services via POSIX signal primitives
- Message-passing services—the microkernel handles the routing of all messages between all threads throughout the entire system.
- Synchronization services via POSIX thread-synchronization primitives.
- Scheduling services—the microkernel schedules threads for execution using the various POSIX realtime scheduling policies.
- Timer services—the microkernel provides the rich set of POSIX timer services.
- Process management services—the microkernel and the process manager together form a unit (called procnto ). The process manager portion is responsible for managing processes, memory, and the pathname space.
Unlike threads, the QNX Neutrino microkernel itself is never scheduled for execution. The processor executes code in the microkernel only as the result of an explicit kernel call, an exception, or in response to a hardware interrupt.
All OS services, except those provided by the mandatory microkernel/process manager module (procnto), are handled via standard processes. A richly configured system could include the following:
- File system managers
- Character device managers
- Native network manager
System processes vs user-written processes
System processes are essentially indistinguishable from any user-written program—they use the same public API and kernel services available to any (suitably privileged) user process. It is this architecture that gives the BlackBerry 10 OS unparalleled extensibility. Since most OS services are provided by standard system processes, it's very simple to augment the OS itself: just write new programs to provide new OS services.
In fact, the boundary between the operating system and the application can become very blurred. The only real difference between system services and applications is that OS services manage resources for clients.
Suppose you have written a database server—how should such a process be classified?
Just as a file system accepts requests (via messages) to open files and read or write data, so too would a database server. While the requests to the database server may be more sophisticated, both servers are very much the same in that they provide an API (implemented by messages) that clients use to access a resource. Both are independent processes that can be written by an end-user and started and stopped on an as-needed basis.
A database server might be considered a system process at one installation, and an application at another. The important point is that the OS allows such processes to be implemented cleanly, with no need for modifications to the standard components of the OS itself. For developers creating custom embedded systems, this provides the flexibility to extend the OS in directions that are uniquely useful to their applications, without needing access to OS source code.
Device drivers allow the OS and application programs to make use of the underlying hardware in a generic way (for example, a disk drive, a network interface). While most OSs require device drivers to be tightly bound into the OS itself, device drivers for BlackBerry 10 OS can be started and stopped as standard processes. As a result, adding device drivers doesn't affect any other part of the OS—drivers can be developed and debugged like any other application.
Last modified: 2015-03-31