Home
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
OS Components & Operations
System Architecture
The System Architecture guide accompanies the QNX Neutrino RTOS and is intended for both application developers and end-users.
Filesystems
The QNX Neutrino RTOS provides a rich variety of filesystems. Like most service-providing processes in the OS, these filesystems execute outside the kernel; applications use them by communicating via messages generated by the shared-library implementation of the POSIX API.
Filesystem classes
The many filesystems available can be categorized into the following classes:

QNX Momentics IDE User's Guide
This User's Guide describes version 7.1 of the Integrated Development Environment (IDE) that's part of the QNX Momentics tool suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running QNX Neutrino 7.1.
- Quickstart Guide
- OS Components & Operations
  - Adaptive Partitioning User's Guide
  - Boot Optimization Guide
    The Boot Optimization Guide describes techniques you can use to reduce the time from your board's initial power on until you have a fully functional QNX system running on the board.
  - Building Embedded Systems
    The Building Embedded Systems guide is intended for developers who are developing or building BSPs for QNX Neutrino RTOS embedded systems.
  - Core Networking Stack User's Guide
    This guide introduces you to the QNX Neutrino Core Networking stack and its manager, io-pkt.
  - Customizing a BSP
    While QNX provides Board Support Packages (BSPs) for many common platforms and their individual variants, in some cases, you need a BSP for a board that QNX does not provide. If this is the case, you can modify a QNX BSP or develop your own.
  - Device Publishers Developer's Guide
  - High Availability Framework Developer's Guide
  - High-Performance Networking Stack (io-sock) User's Guide
    This guide contains instructions for implementing and using the QNX Neutrino High-Performance Networking Stack and its manager, io-sock.
  - Instant Device Activation
  - Migrating to QNX SDP 7.1
  - PCI Server User's Guide
  - Persistent Publish/Subscribe Developer's Guide
  - Platform-independent Publish/Subscribe Developer's Guide
    This guide is intended for application developers who want to use the Platform-independent Publish Subscribe (PiPS) framework to exchange information with other applications. First, the overall PiPS design and data-exchange model are explained. Then, tutorials on using PiPS are given. These tutorials cover key tasks such as selecting a publish-subscribe provider to use and writing plugins that read and write custom data types.
  - QDB Developer's Guide
  - QNX Helpers Developer's Guide
    These libraries provide QNX helpers, including helpers that assist with logging, string conversion, and number and type sizes.
  - SMMUMAN User's Guide
  - System Analysis Toolkit (SAT) User's Guide
  - System Architecture
    The System Architecture guide accompanies the QNX Neutrino RTOS and is intended for both application developers and end-users.
    - The Philosophy of the QNX Neutrino RTOS
      The primary goal of the QNX Neutrino RTOS is to deliver the open systems POSIX API in a robust, scalable form suitable for a wide range of systems—from tiny, resource-constrained embedded systems to high-end distributed computing environments. The OS supports several processor families, including x86 and ARM.
    - The QNX Neutrino Microkernel
      The microkernel implements the core POSIX features used in embedded realtime systems, along with the fundamental QNX Neutrino message-passing services.
    - Interprocess Communication (IPC)
      Interprocess Communication plays a fundamental role in the transformation of the microkernel from an embedded realtime kernel into a full-scale POSIX operating system. As various service-providing processes are added to the microkernel, IPC is the glue that connects those components into a cohesive whole.
    - The Instrumented Microkernel
      An instrumented version of the microkernel (procnto-instr) is equipped with a sophisticated tracing and profiling mechanism that lets you monitor your system's execution in real time. The procnto-instr module works on both single-CPU and SMP systems.
    - Multicore Processing
    - Process Manager
      The process manager is capable of creating multiple POSIX processes (each of which may contain multiple POSIX threads).
    - Dynamic Linking
      In a typical system, a number of programs will be running. Each program relies on a number of functions, some of which will be standard C library functions, like printf(), malloc(), write(), etc.
    - Resource Managers
      To give the QNX Neutrino RTOS a great degree of flexibility, to minimize the runtime memory requirements of the final system, and to cope with the wide variety of devices that may be found in a custom embedded system, the OS allows user-written processes to act as resource managers that can be started and stopped dynamically.
    - Filesystems
      The QNX Neutrino RTOS provides a rich variety of filesystems. Like most service-providing processes in the OS, these filesystems execute outside the kernel; applications use them by communicating via messages generated by the shared-library implementation of the POSIX API.
      - Filesystems and pathname resolution
        You can seamlessly locate and connect to any service or filesystem that's been registered with the process manager. When a filesystem resource manager registers a mountpoint, the process manager creates an entry in the internal mount table for that mountpoint and its corresponding server ID (i.e., the nd, pid, chid identifiers).
      - Filesystem classes
        The many filesystems available can be categorized into the following classes:
        Filesystems as shared libraries
        Since it's common to run many filesystems under the QNX Neutrino RTOS, they have been designed as a family of drivers and shared libraries to maximize code reuse. This means the cost of adding an additional filesystem is typically smaller than might otherwise be expected.
        io-blk
        Most of the filesystem shared libraries ride on top of the Block I/O module.
        Filesystem limitations
        POSIX defines the set of services a filesystem must provide. However, not all filesystems are capable of delivering all those services.
      - Image filesystem
        Every QNX Neutrino system image provides a simple read-only filesystem that presents the set of files built into the OS image.
      - RAM filesystem
        Every QNX Neutrino system also provides a simple RAM-based filesystem that allows read/write files to be placed under /dev/shmem.
      - Embedded transaction filesystem (ETFS)
        ETFS implements a high-reliability filesystem for use with embedded solid-state memory devices, particularly NAND flash memory.
      - Power-Safe filesystem
        The Power-Safe filesystem is a reliable disk filesystem that can withstand power failures without losing or corrupting data.
      - DOS Filesystem
        The DOS Filesystem, fs-dos.so, provides transparent access to DOS disks, so you can treat DOS filesystems as though they were POSIX filesystems. This transparency allows processes to operate on DOS files without any special knowledge or work on their part.
      - FFS3 filesystem
        The FFS3 filesystem drivers implement a POSIX-like filesystem on NOR flash memory devices. The drivers are standalone executables that contain both the flash filesystem code and the flash device code. There are versions of the FFS3 filesystem driver for different embedded systems hardware as well as PCMCIA memory cards.
      - NFS filesystem
        The Network File System (NFS) allows a client workstation to perform transparent file access over a network. It allows a client workstation to operate on files that reside on a server across a variety of operating systems. Client file access calls are converted to NFS protocol requests, and are sent to the server over the network. The server receives the request, performs the actual filesystem operation, and sends a response back to the client.
      - CIFS filesystem
        Formerly known as SMB, the Common Internet File System (CIFS) allows a client workstation to perform transparent file access over a network to a Windows system, or a UNIX system running an SMB server. Client file access calls are converted to CIFS protocol requests and are sent to the server over the network. The server receives the request, performs the actual filesystem operation, and sends a response back to the client.
      - Linux Ext2 filesystem
        The Ext2 filesystem provides transparent access to Linux disk partitions.
      - Universal Disk Format (UDF) filesystem
      - Apple Macintosh HFS and HFS Plus
        The Apple Macintosh HFS (Hierarchical File System) and HFS Plus are the filesystems on Apple Macintosh systems.
      - Windows NT filesystem
        The NT filesystem is used on Microsoft Windows NT and later.
      - Inflator pass-through filesystem
      - QNX Trusted Disk
        QNX Trusted Disk (QTD) devices provide integrity protection of the underlying disk data in secure boot environments. They can extend the secure boot chain up to the core operating system filesystem that stores the critical binaries and configuration files.
      - Filesystem events
        Keeping up with a very live filesystem that changes often and quickly is a challenge for the programs that work with it. To help with this challenge, QNX Neutrino includes filesystem events.
    - PPS
      The QNX Neutrino Persistent Publish/Subscribe (PPS) service is a small, extensible publish/subscribe service that offers persistence across reboots. It's designed to provide a simple and easy-to-use solution for both publish/subscribe and persistence in embedded systems, answering a need for building loosely connected systems using asynchronous publications and notifications.
    - Character I/O
      A key requirement of any realtime operating system is high-performance character I/O.
    - Networking Architecture
      As with other service-providing processes in the QNX Neutrino RTOS, the networking services execute outside the kernel. Developers are presented with a single unified interface, regardless of the configuration and number of networks involved.
    - Native Networking (Qnet)
      In the Interprocess Communication (IPC) chapter earlier in this manual, we described message passing in the context of a single node. But the true power of the QNX Neutrino RTOS lies in its ability to take the message-passing paradigm and extend it transparently over a network of microkernels. This chapter describes QNX Neutrino native networking (via the Qnet protocol).
    - TCP/IP Networking
      As the Internet has grown to become more and more visible in our daily lives, the protocol it's based on—IP (Internet Protocol)—has become increasingly important. The IP protocol and tools that go with it are ubiquitous, making IP the de facto choice for many private networks.
    - High Availability
      The term High Availability (HA) is commonly used in telecommunications and other industries to describe a system's ability to remain up and running without interruption for extended periods of time.
    - Adaptive Partitioning
    - What is Real Time and Why Do I Need It?
    - Glossary
  - Technotes
  - User's Guide
    The QNX Neutrino User's Guide is intended for all users of a QNX Neutrino RTOS system, from system administrators to end users.
- Audio & Graphics API
- Multimedia
- Networking Middleware
- Programming
- Sensor Framework
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX Neutrino RTOS system and developers who want to create a QNX Neutrino resource manager free from vulnerabilities.
- Utilities & Libraries
QNX Hypervisor
The QNX Hypervisor allows you to run multiple OSs on a target system so you can separate critical and non-critical functions, support a wide variety of applications, and reduce hardware costs.
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX software in Amazon Web Services (AWS) and Microsoft Azure (Azure).
QNX Advanced Virtualization Frameworks User's Guide
This User's Guide is aimed at all systems integrators and developers who want to design and build embedded systems using the QNX Advanced Virtualization Frameworks.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation and explains how to obtain technical support.

Filesystem classes

The many filesystems available can be categorized into the following classes:

Image: A special filesystem that presents the modules in the image and is always present. Note that the procnto process automatically provides an image filesystem and a RAM filesystem.
Block: Traditional filesystems that operate on block devices like hard disks and DVD drives. This includes the Power-Safe filesystem, DOS, and Universal Disk Format filesystems.
Flash: Nonblock-oriented filesystems designed explicitly for the characteristics of flash memory devices. For NOR devices, use the FFS3 filesystem; for NAND, use ETFS.
Network: Filesystems that provide network file access to the filesystems on remote host computers. This includes the NFS and CIFS (SMB) filesystems.
Pass-through: Filesystems that sit in front of another filesystem and manipulate files that are in the underlying filesystem. This includes the Inflator filesystem, which uncompresses files that were previously compressed (using the deflate utility).
Note:
Running more than one pass-through filesystem or resource manager on overlapping pathname spaces might cause deadlocks.
Virtual: Filesystems in which the files or directories aren't necessarily tied directly to the underlying media, perhaps being manufactured on-demand. This includes the /proc filesystem; see Controlling processes via the /proc filesystem in the Processes chapter of the QNX Neutrino Programmer's Guide.

Page updated: March 12, 2026