The technology behind QNX

QNX

was originally developed as a real time operating system (RTOS) for embedded

systems. An embedded system is a system where the main processor and the code to

control it are placed together compactly. These systems are used for devices

like mobile phones, PDAs; ‘intelligent’ microwave ovens, washing machines,

refrigerators; and hardware devices for the Internet and networking. These

devices operate in real time, meaning that the time delay between the input and

the output is predictable, unlike non real-time devices where this time can’t

be determined. So, the better the ‘responsiveness’ of the instruction set of

an operating system (OS), the better is its real-time response. OSs like QNX

that enable embedded devices to run in real-time came to be called real time OSs.

Such OSs are very small in size, making it possible to fit them on small

solid-state memory modules.

QNX later branched off as a platform OS that runs on ordinary desktop

computers. A platform OS is an OS that runs on various hardware platforms, say

the PPC and x86. Some examples of such OSs are Windows and Mac OS. These are

end-user environments.

Because QNX is a cross between a real time and a platform OS, it is called

QNX RTP (Real Time Platform). The real time version of QNX is known as Neutrino,

which is the base for the RTP and on which the features of a platform OS are

added. In this article, we’ll look at QNX’s architecture, the making of its

applications, and its memory and internal communication.

The architecture of QNX

Since QNX RTP is built on Neutrino, it inherits all features of the Neutrino

RTOS. The Neutrino has a microkernel (that is, a small core of the OS)

architecture. The kernel handles the main services, like threads, messaging,

condition variables, signals, and scheduling, within the OS. Neutrino, in

specific, provides multitasking, threads, priority-driven preemptive scheduling,

and fast context switching. Other processes related to end-user applications

will access these services from the kernel. Since the microkernel is very small,

it’s quicker in handling things. It doesn’t have services like file systems,

device I/O, and networking, that are normally found in conventional OS kernels.

Instead, it has optional processes to provide these services. In fact, even the

process manager is an optional component.

In QNX RTOS, the processes run in their own memory-protected addresses. So

the core doesn’t get affected if any of the processes crash. This is the base

for QNX RTP, making it highly stable. The kernel is composed of POSIX

standard-API and is not related in any way to the Unix kernel as many users may

think. This also makes it suitable for development in cross-platform

environments.

The making of QNX applications

Applications in QNX are modular, meaning the software and even the device

drivers are plugged into the microkernel. This makes QNX highly scalable and apt

for devices, right from ones that are short on system resources to high-end

workstations or servers. The Photon microGUI, which is the graphical interface

for the OS, is also based on a similar architecture. Any software developed for

Neutrino is in the form of modules that can be dynamically plugged into it. This

is also true for any additions or enhancements to existing modules in the OS.

So, unlike in conventional development, you don’t have to recompile and relink

the whole program code of the software for testing. Only the modules that are

changed or added, need to be compiled, linked, and tested. The kernel and the

existing tested modules can be left as such. This is supposed to reduce the time

required for development. A lot of development tools are also incorporated in

the QNX RTP distribution and you have a choice of both command-line GNU

development and a graphical environment with the Photon microGUI. There is also

a very strong developer community for QNX.

QNX’s memory and internal communication

We talked of the protected memory environment that gives QNX its stability.

Embedded systems have something called hardware watchdog timers. These are built

into the hardware and keep an eye on all processes. They reset the processor if

a process goes haywire. This can lead to system restarts and memory dumps. What

QNX RTOS employs is a software watchdog. So if an error occurs while a process

is running, the OS detects and passes it over to a user written thread, which

could make an intelligent decision. This helps reduce system downtime.

Inter Process Communication (IPC) is a very important component for reliable

communication and working of an OS. QNX claims to be the first OS to use

message-passing as a means of IPC. This method brings consistency in the

communication, be it local or over the network. In other words, when

applications are accessing a resource, they don’t know whether it’s on the

local machine or somewhere on the network.

This was just an outline of the kind of technology that goes behind QNX RTP.

For those who want more insight, check out the QNX developers network at http://qdn.qnx.com.

You can also subscribe to newsgroups at news://inn.qnx.com.

Ashish Sharma