ALLPCB
Introduction
This article compares QNX and Linux from the perspective of application development on SoC/AP platforms, focusing on practical differences that matter when porting code or deploying applications. It does not discuss macrokernel vs microkernel theory; instead it highlights API, filesystem, tooling, and runtime behavior differences that affect developers.
Fundamental differences
- QNX is a microkernel; Linux is a monolithic kernel.
- QNX is designed as a hard real-time operating system; Linux is generally considered soft real-time unless augmented with RT patches.
- Both are Unix-like operating systems.
- QNX supports the POSIX PSE54 profile; Linux implements POSIX but may not fully conform to PSE54.
- Scheduling: Linux supports SCHED_FIFO, SCHED_RR, SCHED_OTHER, SCHED_DEADLINE, and batch policies. QNX supports priority-based scheduling, RR, and FIFO, with differences in behavior and configuration.
- IPC: Linux supports POSIX IPC and System V IPC. QNX supports POSIX IPC and provides its own message-passing primitives. Functionally they are comparable, but details differ.
- Performance tuning and extreme optimization require platform-specific abstractions to maintain portability.
- Filesystems differ between the two systems.
Application-level differences
Root filesystem layout
Typical Linux root contains directories such as bin, dev, home, lib, opt, sbin, sys, usr, data, etc, proc, tmp, var. Executables are usually in bin, libraries in lib or usr/lib, tmp is cleared on reboot, etc stores configuration, proc exposes runtime process information, and dev maps kernel devices to device nodes.
QNX root commonly contains debug, dev, etc, lib, opt, proc, bin, sbin, tmp, usr, var. Command-line utilities and related libraries are often found under debug. The QNX /proc content is much smaller than Linux /proc; software that relies on Linux-style /proc content needs special attention when porting. Other directories are broadly similar.
Command-line tools
Embedded builds of both QNX and Linux are typically trimmed, so not all commands are guaranteed to be present. Basic file operations (ls, pwd, cd, cp, rm) and df -h behave similarly on both systems.
Mount and unmount differ: on QNX use a mount syntax like
mount /dev/xxx /yyy, and
umount -f xxx to unmount.
Performance analysis tools differ significantly. QNX provides utilities such as hogs, pidin, and ps for process inspection. QNX does not provide strace; instead it offers tracelogger and traceprinter and kernel event tracing. Linux provides strace and perf for system call tracing and profiling. Valgrind is available on QNX for memory analysis; on Linux it must be installed separately.
QNX supports remote debugging similar to gdb and can generate core dumps; the mechanisms differ from Linux but provide equivalent capabilities. QNX also provides priority-inversion detection features that are not commonly available as mature solutions on Linux.
Code coverage workflows are similar in principle, but toolchain support (for example gtest support on QNX) should be verified.
Network analysis and tools
Linux provides a wide range of network tools and libraries including tcpdump, libpcap, iperf, ss, netstat, ifconfig/ip, ping, lsof, arp, and supports kernel features such as BPF and netfilter. These are useful for NIC diagnostics, performance testing, packet capture, port listing, connection inspection, and traffic analysis.
QNX has fewer network analysis tools. ifconfig and ping behave similarly. QNX provides sockstat to list sockets including Unix domain sockets, and netstat can show network status and packet loss. iperf3 and arp are typically available. However, libpcap and BPF/netfilter are generally not available on QNX, which limits packet-capture workflows that depend on those facilities.
Be aware that some QNX command implementations may exhibit noticeable latency in response under certain configurations; account for that when using interactive tools or scripts.
System programming differences
The following sections summarize differences in common system programming areas.
Process creation
Linux commonly uses fork()+exec family. QNX does not support fork; processes must be created with the posix_spawn family. Linux also supports posix_spawn, but many Linux codebases rely on fork.
Threads
Both systems use the pthread API. Note that pthread_setname_np may not have effect on QNX even though the call succeeds; behavior differs between platforms and should be tested.
Locks and semaphores
POSIX semaphore APIs (sem_*) are supported on both QNX and Linux. System V IPC is not supported on QNX.
Shared memory
POSIX shared memory APIs (shm_*) are supported on both systems. QNX creates shared memory objects under /dev/shmem whereas Linux uses /dev/shm. Naming semantics differ when using path-like names (for example, names that include slashes) and should be tested, as behavior may vary while calls succeed.
Network programming
Basic BSD sockets for UDP/TCP are compatible between QNX and Linux. However, Linux-specific features such as BPF, libpcap, netfilter, and certain socket options are not available on QNX. Linux allows setting priority on sockets and exposes many kernel-level hooks used by projects like linuxptp; such projects may not compile or run on QNX without modification. Raw-socket development or kernel-assisted optimizations often require platform-specific changes. Pay special attention to setsockopt usage and any features that rely on Linux kernel extensions.
Timers
Linux exposes multiple timer interfaces: alarm, timer_create/timer_settime, setitimer, etc. QNX documentation indicates support for these interfaces; compatibility should be verified in practice for targeted QNX versions.
Signals
Basic signal APIs (signal, sigaction) are compatible between the platforms for common uses; advanced usage should be tested.
Build and toolchain differences
Cross-compiling for Linux typically does not require explicit glibc specification or special environment initialization beyond a standard cross-toolchain.
Cross-compiling for QNX requires sourcing the QNX environment setup script (for example qnxxxx_env) and explicitly linking the C library with -lc. QNX supports both qcc and gcc frontends; both can produce executables for QNX. C++ builds must specify the standard (for example gnu++11) and link with -lc++. To use GNU extensions you may need to explicitly request the gnu++ standard. Socket programming often requires linking -lsocket. Overall, QNX cross-compilation has more explicit configuration steps.
Summary
QNX and Linux are both Unix-like but differ in kernel architecture, real-time characteristics, supported kernel features, and tooling. Many POSIX APIs are common to both, but platform-specific differences in /proc content, IPC semantics, network facilities, debugging tools, and build toolchain requirements can affect portability. When targeting both platforms, identify and abstract platform-dependent functionality early, and validate assumptions about /proc, socket options, and build/link flags.
