How QNX Neutrino is unique

The QNX Neutrino RTOS 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 Neutrino architecture.

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 Neutrino in the System Architecture guide.

QNX Neutrino'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.

Developers can usually eliminate interrupt handlers (typically the most tricky code of all) by moving the hardware manipulation code up to the application thread level—with all the debugging advantages and freedom from restrictions that that implies. This gives QNX Neutrino an enormous advantage over monolithic systems.

Likewise, in installations in the field, the modularity of QNX Neutrino'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 Neutrino'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 Neutrino'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 Neutrino's microkernel architecture lets developers scale the code down to fit in a very constrained embedded system, but QNX Neutrino is powerful enough to use as a desktop OS. QNX Neutrino runs on multiple platforms, including x86, and ARM. It supports symmetric multiprocessing (SMP) and bound multiprocessing (BMP) on multicore systems with up to 32 processors; for more information, see the Multicore Processing chapter of the QNX Neutrino Programmer's Guide.

QNX Neutrino also features the Qnet protocol, which provides transparent distributed processing; you can access the files or processes on any machine on your network as if they were on your own machine.