ROSS A.

MCKEGNEY
STUDENT #: 426 7519

7 JUNE 2000
RMC EEE 551 – QNX REALTIME OPERATING SYSTEMS

1. ABOUT QSSL

1.1 The Company

QNX Software Systems Ltd. (QSSL) was formed in 1980 by Dan Dodge and Gord Bell. The
original OS was called QUNIX (Quantum UNIX), which after prompting from AT&T was
changed to QNX. Shortly after, QNX 2 was introduced – targeting the 8088 processor. QNX 4
was introduced in 1990 – providing support for 32bit operations and POSIX compliant. In 1995,
QNX Neutrino was introduced as an alternative OS – designed to meet the needs of a wider
spectrum of embedded devices. Recently, QNX has made its development environment and
samples of both RTOSs freely available.

1.2 Universal Process Model Architecture

Both QNX 4 and Neutrino use a microkernel architecture (which they call a Universal Process
Model architecture). In contrast to realtime executive and monolithic kernel architectures, UPM
offers memory protection for all system and user-level processes. The following diagrams
demonstrate this difference in philosophy:

Figure 1.2: RTOS Architectures

1.3 Other Products
QSSL provides several other products related to their RTOSs. These include:
• Photon microGUI
• Voyager Web Browser
• Filesystems: POSIX (fsys), Embedded filesystem (Efsys), Server Message Block (SMBfsys),
Network (NFS), DOS (Dosfsys), CD-ROM (Iso9660fsys), Block (Blkfsys).
• Device management
• FLEET High performance networking
• X window system
• QNX Windows
Third party products are also available. These will be discussed later in the document.

2. QNX 4 RTOS
This section will discuss the QNX 4 RTOS. Contents come from [QNX00] and [Krt98].

2.1 QNX 4 Philosophy

The QNX 4 RTOS is based on a very small microkernel which coordinates the interaction of
system and user processes via message passing.

2.2 Microkernel
The QNX 4 microkernel has four main responsibilities:
• IPC: Inter-process communication mechanisms include blocking send(), receive(), reply()
and asynchronous signals and proxies. Message data is copied directly from one processes
address space to another’s, and message queues are not explicitly supported.
• Network Interface: The kernel provides a mechanism for fast and transparent IPC between
QNX nodes connected to a LAN.
• Scheduling: When multiple processes are ready to run at the same priority level, the kernel
uses the associated scheduling algorithm to choose which goes first. Supported algorithms are
FIFO, Round Robin, and adaptive (similar to round-robin, but if a process uses up its entire
time slice its priority is decremented).
• Interrupt redirection: When a hardware interrupt occurs, the kernel is responsible for
spawning the appropriate handler routine.
System processes are responsible for all other OS functionality; these include the Process
Manager, Filesystem managers, Device managers, and Network managers. In this way the RTOS
can be scaled to fit virtually any system requirements.
2.3 Process Manager
The process manager is responsible for creating new processes, and for managing process
resources. This is a required process (i.e. QNX 4 cannot be configured without it), and is the only
process that shares address space with the kernel.
QNX programmers are provided with four primitives for process creation:
• exec(): Temporarily replace the current process with another process.
• spawn(): Create a new process, and run it.
• fork(): Create a duplicate of the current process, and run it.
• tfork(): Like fork, but spawns a thread.
Depending on the primitive selected, different process information (e.g. process ID, data, open
files, etc.) will be inherited from the current process.
The process manager also manages timers, which are implemented using a simple mechanism:
the system clock delivers periodic interrupts, which are handled by the ISR in the kernel; the
system will update its ‘time-of-day’ variable to reflect the passing of time, and compare this with
the expiry times of all running timers; if a timer has expired, it will be put at the end of the queue
for its priority; when run, the timer will send either a signal or a proxy.

2.4 Filesystem Managers

Filesystem managers are system processes responsible for handling all requests to open, close,
read, and write files. Supported filesystem types include: DOS Filesystem, CD-ROM filesystem,
Flash, NFS, and SMB. Supported file types are as follows:
• Regular files: randomly accessible sequences of bytes.
• Directories: contain information needed to locate regular files AND status and attribute
information for these files.
• Symbolic links: pathname to a file or directory.
• Pipes and FIFOs: I/O channels between cooperating processes.
• Block special files: devices such as disk drives and partitions.
Filesystem managers may also support the following performance optimization techniques:
• Elevator Seeking: outstanding I/O requests are ordered so that they can be read with one
sweep of the disk head.
• Buffer Cache: intelligent cache to reduce the number of times a file has to be read.
• Multi-threading: allows accessing multiple devices simultaneously
• Client-driven Priority: (optional) filesystem manager may have its priority driven by the
process sending the request.
• Temporary Files: (optional) keeps temporary files in cache, only writing to disk if
absolutely necessary.
• Ramdisks: Integrated ramdisk capability, allowing up to 8mb of memory to be used as a
simulated disk.
Note that since filesystem managers are optional processes, filesystems can be added and
removed on the fly.

2.5 Device Managers

QNX 4 device managers provide an interface between processes and devices, allowing read(),
write(), open(), and close() operations. Typically this is implemented as three shared memory
queues: input, output, and canonical. To read data from a device (e.g. a serial port) the associated
device manager would simply copy data from the input queue (or the canonical queue if data is to
be read in ‘edited’ mode) to the requesting process’ receive buffer. To write data to a device (e.g.
to a printer attached to a parallel port), the associated device manager would copy data from the
requesting process to the output queue associated with that device.
Again, because device managers are optional processes, device-types can be easily added or
removed on the fly.

2.6 Network Manager

The network manager coordinates with the networking portion of the QNX kernel to support IPC
between distributed processes. QSSL calls this type of networking technology FLEET (Fault-
tolerant networking, Load-balancing on the fly, Efficient performance, Extensible architecture,
Transparent distributed processing). Note that this only works between nodes running the QNX 4
kernel; it does not work between QNX 4 and Neutrino nodes, or between QNX 4 and nodes
running other OSs. For these types of communication, other network protocols must be used (e.g.
TCP/IP).
Sending a message to a distributed node is fairly simple, and transparent:
1. Process calls Send() or Reply(), Microkernel puts the data into the appropriate virtual circuit
buffer.
2. Microkernel enqueues to the network manager a time-ordered queue entry identifyin the
sender, the remote receiver, and pointers to the data in the VC.
3. Network manager dequeues the queue entry.
4. Network manager passes the entry along to the appropriate network driver.
5. Network driver begins transmission on the network media.
Receiving the message on a distributed node is equally straightforward:
1. Network driver puts message data into the appropriate VC buffer.
2. Network driver informs the network manager that the delivery is complete.
3. Network manager uses a private kernel call to inform the microkernel that delivery is
complete.
4. Microkernel puts data from VC buffer into the process’s buffer.
Notice that hardware specific code is kept in device drivers, not in the network manager. This
means that network devices can be changed dynamically, and that multiple physical networks can
operate simultaneously.
The network manager also supports automatic load balancing (i.e. automatically select the most
appropriate network driver) and fault-tolerance (i.e. if one network fails, messages are
automatically transmitted by another means.
2.7 Photon microGUI
QNX 4 supports the Photon microGUI graphical user interface. Like the RTOS itself, Photon is
based on a simple microkernel that can be extended (i.e. decorated) to a variety of levels of
sophistication. Optional processes communicate via IPC, and respond to input and output events
(called photons); examples of photons include mouse clicks, window drawing, etc..

3. QNX NEUTRINO RTOS

3.1 Neutrino Philosophy

The Neutrino RTOS was designed to “…deliver the open systems POSIX API in a robust,
scalable form suitable for a wide range of systems – from tiny, resource-constrained systems to
high-end distributed computing environments” [QNX00].

3.2 Neutrino Microkernel

The Neutrino microkernel provides the following services:
• Thread services: Processes act only as containers for threads, defining the address space.
Note that processes are memory protected, threads are not.
• Signal services: Neutrino has a sophisticated event-handling subsystem based on POSIX
signals, and proprietary signals.
• Message-passing services: Essentially IPC between threads, supporting message passing,
signals, POSIX message queues, shared memory, Pipes, FIFOs.
• Synchronization services: Mutexes, condition variables, sleepon locks, reader/writer locks,
semaphores, FIFO scheduling, Send/Receive/Reply, Atomic operations.
• Scheduling services: Scheduling on threads, using FIFO and round-robin scheduling
algorithms.
• Timer services: Full POSIX timer functionality. Expire on an absolute date, a relative date,
or cyclical.
The Neutrino system processes include: Process manager, Filesystem managers, Character device
managers, Graphical user interface (photon), Native network manager, TCP/IP.

3.3 SMP with Neutrino

Two versions of Neutrino available, one with support for Symmetric Multiprocessing (SMP). The
SMP version has only a slightly larger footprint, and will boot on any system that conforms to the
Intel MultiProcessor Specification with up to 8 Pentium or Pentium Pro processors. Threads are
scheduled transparently to any available processor. Critical sections use the same synchronization
primitives as uni-processor systems.

3.4 Process Manager

Unlike QNX 4, Neutrino does not need the process manager. However, if Neutrino is configured
without a process manager, then there will be only one address space within which the system can
create threads but not processes. With the process manager comes process management, memory
management, and namespace management.
Neutrino supports the following process creation primitives:
• spawn(): Just like spawn() in QNX 4.
• fork(): Just like fork() in QNX 4. Note that this should only be used for processes with one
thread.
• vfork(): Used in cases where a call to exec() will immediately follow. Does not copy data,
continues to use calling process’ data until the call to exec() is made.
• exec(): Just like exec() in QNX 4.
Note that tfork() is not supported; thread creation uses the POSIX command pthread_create().
The process manager also provides support for memory protection (so that if one process goes
down it won’t take anything else with it). Unlike QNX 4, memory protection is optional – the
programmer can select full protection or no protection. There is a small space overhead for
memory protection.
Finally, the process manager supports namespace management. Resource manager processes
(which manage I/O devices) are given a subset of the pathname space as their “domain of
authority”.

3.5 Dynamic Linking

Neutrino supports dynamic linking of objects. This allows many applications to share
components that they will load and unload dynamically as required. For example, many
applications will use the standard C library (libc.a). Rather than statically link the library with
every application, it is dynamically loaded only when a program needs it. This can significantly
reduce memory requirements.
The ELF (Executable and Linking Format) binary format is used for shared objects; the following
process is used when a new process is loaded that may contain dynamic components:
1. Load segments (Text and Data) are loaded into memory at the process’s base address.
2. The main stack is created just below the base address, and grows downwards. (Note: If any
threads are allocated, their stacks will be below the main stack).
3. The process manager then decodes the process’s ELF header to determine if it was
dynamically linked. If it was, the name of the dynamic interpreter (points to a shared library
containing the runtime linker code) will be extracted. This shared library will be loaded into
memory.

3.6 Filesystems
Filesystems are resource managers, providing services as defined in the POSIX API: (open(),
close(), read(), write(), lseek(), etc.). This implementation means that: filesystems can be started
and stopped dynamically; multiple filesystems can run concurrently; each filesystem has a
distinct and consistent pathname space. Neutrino supports the same filesystem types as QNX 4
(QNX, POSIX, NFS, etc.)
3.7 TCP/IP Networking
Neutrino supports the BSD TCP/IP protocol using the Neutrino Tiny TCP/IP stack resource
manager. Note that this is an alternative to FLEET networking, but necessary in order to
communicate with nodes that are not running Neutrino.

4. CLASSIFICATION

4.1 Microprocessor Support

QNX 4 Neutrino

x86 MIPS
AMD: Elan SC300, Elan SC310, Elan SC400, IDT: R4700
Elan SC410
NEC: VR4102, VR4111, VR4300, VR5000
Cyrix: Media GX
QED: RM5260, RM5261, RM5270, RM5271
Intel: 386 EX, 486, Pentium, Pentium II,
Various: R4000, R5000
Pentium III, Pentium Pro, ULP 486
PowerPC
STMicroelectronics: STPC
Motorola: 401, 403, 603e, 604e, 750, MPC821,
MPC823, MPC860
x86
AMD: Elan SC300, Elan SC310, Elan SC400,
Elan SC410
Cyrix: Media GX
Intel: 386 EX, 486, Pentium, Pentium II,
Pentium III, Pentium Pro, ULP 486

4.2 Tool Compatibility

Cross development:
• Watcom C/C++
• GNU Tools
• Metrowerks CodeWarrior IDE for QNX Neutrino

Native Development:
• Watcom C/C++
• GNU Tools

Other:
• Photon developer’s toolkit
• Internet Appliance toolkit
• QNX In-Hand Toolkit
• TCP/IP Developer’s Toolkit
• WebPAD
• Third-party Development tools

4.3 Services

QNX 4 Neutrino

POSIX.1b clocks and timers POSIX Threads

Nested interrupts Message passing
Dynamically attachable/removable interrupt Signals
handlers
Clocks
Shared memory
Timers
Built-in local and remote debugging primitives
Interrupt handlers
User-configurable system limits and resources
Semaphores
32 priority levels
Mutual exclusion locks
Preemptive, prioritized context-switching
Condition variables
FIFO, round robin, adaptive scheduling
Preemptive message passing
Servers can have their priority driven by the
messages they receive from clients.

4.4 Footprint
Specific footprint information is difficult to find. The QNX 4 microkernel is approximately 12K
(which means that often it can fit completely in CPU cache). However, a minimal configuration
also requires that the process manager be included. The minimal Neutrino configuration is
slightly smaller, since the kernel can be run standalone. Every aspect of both QSSL RTOSs is
scaleable, from the basic operating system services to the GUI.
To demonstrate the small footprint of its software, QSSL is giving the “1.44M web challenge”.
From their website, they are offering a download that will fit on a diskette, containing the
following: QNX Realtime OS, Photon microGUI, HTML 3.2 web browser, Web server, TCP/IP
with PPP, Internet dialer. When you boot an x86 machine from the floppy, the components are
loaded into RAM.
4.5 Performance

QNX 4* Neutrino

Context Switching Interrupt Latency:

1.95 usec (full, user-level switch) 1.84 usec (P100)

Interrupt Latency: Scheduling latency

4.3 microseconds (P133) 4.73 usec (P100)

Scheduling latency
7.8 usec (P133)

Disk I/O (based on 16384 byte records)

4 Mbytes/s (Read)
5.3 Mbytes/s (Write)

Network Throughput
1.1 Mbytes/s (10 Mbit Ethernet)
7.5 Mbytes/s (100 Mbit Ethernet)

*Based on system with Pentium/133 with an Adaptec 2940 Wide SCSI controller, a Barracuda
SCSI-Wide disk drive, a 100 Mbit PCI-bus Digital 21040 Ethernet card, and a 10Mbit ISA-bus
NE2000 Ethernet card.

4.6 Device Drivers

The QNX website lists hundreds of available device drivers. A resource manager framework is
also provided, which greatly simplifies writing custom device drivers.

4.7 Debugging Tools

QSSL provides the standard GNU debugging tools, as well as built-in local and remote
debugging primitives.

4.8 Standards Compatibility

Both QNX 4 and Neutrino are POSIX.1 certified, and conform to many of the POSIX.1b realtime
extensions. Neutrino is more advanced in this respect, with support for POSIX threads.
4.9 Technical Support
QSSL provides technical support for registered users of their products. There are also freely
available resources, including the news://comp.os.qnx newsgroup and an online developer’s
network (http://www.qnx.com). QSSL also sponsors an annual conference, and publishes training
manuals.

4.10 Licensing
QNX RT-Platform will soon be available free of charge for non-commercial purposes. It
includes:
• QNX neutrino microkernel (single processor and SMP versions)
• OS modules (file systems, networking, etc.)
• Graphical windowing systems (Photon, X-windows)
• Utilities and libraries
• TCP/IP stacks
• GNU tool chain (GCC, G++, GDB, and graphical debugger)
Some source code will also be freely available shortly; only the kernel and other core portions of
the QNX platform will remain protected.

4.11 Reputation
Reputation is a subjective criterion, and should be judged accordingly. QSSL is known for
providing very elegant microkernel-based solutions. They are also known to be driven by their
major customers (particularly Cisco) – which means that if their major customer’s do not demand
a feature, then it will not be given high priority.

5. DISCUSSION

5.1 Suitability for OS Course

Strengths Weaknesses

Elegant Design Limited Target Hardware Support

Canadian Company Kernel source not available
Top contender in the market
Free copy of RTOS and Dev environment
Access to source code
POSIX Compliant
Flexible and scalable
Nice one-disk demo
Runs on x86
“QNX in education” program

5.2 Suitability as Rose-RT Target

Strengths Weaknesses

QNX 4 is a Rose-RT target. Unclear whether Neutrino is supported.

POSIX Compliant
“QNX in education” program

REFERENCES
[Krt98] Krten, R. Getting Started with QNX 4: A Guide for Realtime Programmers. PARSE
Software Devices, 1998.

[QNX97] QNX Software Systems Ltd. QNX Operating System: System Architecture (2nd
Edition). October 1997.

[QNX00] QNX Software Systems Ltd. Home Page. http://www.qnx.com. Available 2000.