How QNX OS is unique

Updated:
QNX SDP8.0User's GuideUser

The QNX OS consists of a microkernel (procnto) and various processes. Each process—even a device driver—runs in its own virtual memory space.

Figure 1. The QNX OS architecture.
The microkernel and system processes

The advantage of using virtual memory is that one process can't corrupt another process's memory space. For more information, see The Philosophy of QNX OS in the System Architecture guide.

QNX OS's most important features are its microkernel architecture and the resource manager framework that takes advantage of it (for a brief introduction, see Resource managers). Drivers have exactly the same status as other user applications, so you debug them using the same high-level, source-aware, breakpointing IDE that you'd use for user applications. This also means that:

  • You aren't also debugging the kernel when you're debugging a driver.
  • A faulty driver isn't likely to crash the OS.
  • You can usually stop and restart a driver without rebooting the system.

Likewise, in installations in the field, the modularity of QNX OS's components allows for the kind of redundant coverage expressed in our simple, yet very effective, High Availability (HA) manager, making it much easier to construct extremely robust designs than is possible with a more fused approach. People seem naturally attracted to the ease with which functioning devices can be planted in the POSIX pathname space as well.

Developers, system administrators, and users also appreciate QNX OS's adherence to POSIX, the realtime responsiveness that comes from our devotion to short nonpreemptible code paths, and the general robustness of the microkernel.

CAUTION: Some x86 systems can run in System Management Mode (SMM), where the BIOS installs special code that runs when a System Management Interrupt (SMI) occurs. SMI interrupts may be generated by the motherboard or peripheral hardware, and can't be masked by the operating system. When SMM is entered, normal operations—including the OS—are suspended, and the SMI handler runs at a high priority. Avoid using systems where SMM can't be disabled, because it can destroy QNX OS's realtime performance. The OS can't do anything about the delays that SMM introduces, nor can the OS even detect that the system has entered SMM.

QNX OS's microkernel architecture lets developers scale the code down to fit in a very constrained embedded system, but QNX OS is powerful enough to use as a desktop OS. QNX OS runs on multiple platforms, including x86_64, and AArch64. It supports symmetric multiprocessing (SMP) and bound multiprocessing (BMP) on multicore systems with up to 64 processors; for more information, see the Multicore Processing chapter of the QNX OS Programmer's Guide.