Editing QNX (section)

== Technology ==

As a [[microkernel]]-based OS, QNX is based on the idea of running most of the [[operating system]] [[Kernel (operating system)|kernel]] in the form of a number of small tasks, named Resource Managers. This differs from the more traditional [[monolithic kernel]], in which the operating system kernel is one very large program composed of a huge number of parts, with special abilities. In the case of QNX, the use of a microkernel allows users (developers) to turn off any functions they do not need without having to change the OS. Instead, such services will simply not run.

The QNX kernel, <code>procnto</code> (also name of the binary executable program for the QNX Neutrino ('nto') process ('proc') itself), contains only [[Scheduling (computing)|CPU scheduling]], [[interprocess communication]], [[interrupt]] redirection and timers. Everything else runs as a user process, including a special process known as <code>proc</code> which performs process creation and [[memory management]] by operating in conjunction with the [[microkernel]]. This is made possible by two key mechanisms: subroutine-call type interprocess communication, and a [[boot loader]] which can load an image containing the kernel and any desired set of user programs and shared libraries. There are no [[device drivers]] in the kernel. The network stack is based on [[NetBSD]] code.<ref name="core-64"/> Along with its support for its own, native, device drivers, QNX supports its legacy, ''io-net manager'' server, and the network drivers ported from NetBSD.<ref name="net-wiki"/>

QNX interprocess communication consists of sending a message from one process to another and waiting for a reply. This is a single operation, called <code>MsgSend</code>. The message is copied, by the kernel,{{Citation needed|date=June 2014}} from the address space of the sending process to that of the receiving process. If the receiving process is waiting for the message, control of the CPU is transferred at the same time, without a pass through the CPU scheduler. Thus, sending a message to another process and waiting for a reply does not result in "losing one's turn" for the CPU. This tight integration between message passing and CPU scheduling is one of the key mechanisms that makes QNX message passing broadly usable. Most [[Unix]] and [[Linux]] interprocess communication mechanisms lack this tight integration, although a [[user space]] implementation of QNX-type messaging for Linux [[SIMPL|does exist]]. Mishandling of this subtle issue is a primary reason for the disappointing performance of some other microkernel systems such as early versions of [[Mach (kernel)|Mach]].{{Citation needed|date=January 2012}} The recipient process need not be on the same physical machine.

All I/O operations, file system operations, and network operations were meant to work through this mechanism, and the data transferred was copied during message passing. Later versions of QNX reduce the number of separate processes and integrate the network stack and other function blocks into single applications for performance reasons.

Message handling is prioritized by [[thread (computer science)|thread]] priority. Since I/O requests are performed using message passing, high priority threads receive I/O service before low priority threads, an essential feature in a [[hard real-time]] system.

The boot loader is the other key component of the minimal microkernel system. Because user programs can be built into the boot image, the set of device drivers and support libraries needed for startup need not be, and are not, in the kernel. Even such functions as program loading are not in the kernel, but instead are in shared user-space libraries loaded as part of the boot image. It is possible to put an entire boot image into [[Read-only memory|ROM]], which is used for diskless embedded systems.

Neutrino supports [[symmetric multiprocessing]] and [[processor affinity]], called bound multiprocessing (BMP) in QNX terminology. BMP is used to improve cache hitting and to ease the migration of non-SMP safe applications to multi-processor computers.

Neutrino supports strict priority-preemptive scheduling and [[Adaptive Partition Scheduler|adaptive partition scheduling]] (APS). APS guarantees minimum CPU percentages to selected groups of threads, even though others may have higher priority. The adaptive partition scheduler is still strictly priority-preemptive when the system is underloaded. It can also be configured to run a selected set of critical threads strictly [[Real-time computing|real time]], even when the system is overloaded.

The QNX operating system also contained a web browser known as 'Voyager'.<ref>{{Cite web|url=http://www.qnx.com/products/middleware/graphics/voyager.html|title=QNX Neutrino RTOS – Embedded OS &#124; BlackBerry QNX &#124; BlackBerry QNX}}</ref>

Due to its [[microkernel]] architecture QNX is also a [[distributed operating system]]. [[Dan Dodge]] and [[Peter van der Veen]] hold {{US patent|6697876|U.S. Patent 6,697,876: Distributed kernel operating system|src=uspto}} based on the QNX operating system's distributed processing features known commercially as Transparent Distributed Processing. This allows the QNX kernels on separate devices to access each other's system services using effectively the same communication mechanism as is used to access local services.{{primary source inline|date=January 2024}}