POSIX

POSIX (Portable Operating System Interface) is an IEEE and Open Group standard designed to ensure source-code portability across Unix-like operating systems, including Linux, macOS, and the BSDs. By defining a universal interface between applications and the operating system kernel, POSIX enables developers to write programs in C or C++ that compile and run seamlessly across different systems without requiring platform-specific code changes.

Beyond signals and core system calls, POSIX standardizes the complete software runtime environment through four main volumes: Base Definitions, System Interfaces (C APIs), Commands & Utilities (CLI/Shell), and Rationale. Together, these specifications cover everything from process execution and multi-threading (pthreads) to memory management (mmap), inter-process communication, network sockets, file system semantics, and standard command-line tools like ls, grep, and the POSIX shell (/bin/sh).

Process Management & Execution Models

• Process Lifecycle: System calls for creating, replacing, and reaping processes (fork(), vfork(), execve(), wait(), waitpid()).
• POSIX Threads (pthreads): The POSIX threads standard (IEEE 1003.1c) specifies thread creation (pthread_create), lifetime management (pthread_join, pthread_detach), and synchronization primitives:
  • Mutexes: pthread_mutex_lock, pthread_mutex_unlock
  • Condition Variables: pthread_cond_wait, pthread_cond_signal
  • Read-Write Locks: pthread_rwlock_rdlock, pthread_rwlock_wrlock
• POSIX Process Groups, Sessions & Job Control: Process topology (PID, PGID, SID), foreground vs. background execution, controlling terminals, SIGHUP disconnection handling, and the canonical daemonization pattern.
• Scheduling: Real-time priority scheduling policies (SCHED_FIFO, SCHED_RR, SCHED_OTHER) and nice values (nice(), sched_setscheduler()).

File Systems, Memory & I/O Architecture

• File Operations & File Descriptors: File creation, read/write primitives, symbolic/hard links, and metadata (open, read, write, close, lseek, stat, chmod, link, symlink, readlink).
• POSIX File Locking (fcntl & OFD): Byte-range advisory record locks (fcntl F_SETLK), Open File Description (OFD) locks (F_OFD_SETLK), and comparisons with BSD flock().
• Asynchronous & Multiplexed I/O: Mechanisms for monitoring file descriptor readiness (select(), poll()) and non-blocking asynchronous I/O (aio_read(), aio_write()).
• Virtual Memory Management: Memory mapping, permission controls, and locking (mmap, munmap, mprotect, madvise, mlock, msync).
• Directory Semantics: Path hierarchy rules (e.g., / root, . current, .. parent, max path length limits) and directory navigation (opendir, readdir, mkdir, rmdir).

Inter-Process Communication (IPC)

The POSIX IPC Suite replaces legacy System V IPC with file-descriptor-friendly, path-named primitives:

• Pipes and FIFOs: Unidirectional data streams (pipe(), mkfifo()).
• POSIX Semaphores: Named (sem_open) and unnamed (sem_init) counting semaphores with guaranteed async-signal safety for sem_post().
• POSIX Shared Memory: Nanosecond-scale, zero-copy shared memory objects mounted via file-like APIs (shm_open, ftruncate, mmap).
• POSIX Message Queues: Priority-based message queues with boundary preservation and asynchronous notifications (mq_open, mq_send, mq_receive, mq_notify).

Signals & Software Interrupts

• POSIX Signals Architecture & sigaction: Reliable signal delivery, sigaction() configuration, signal masks (sigprocmask), async-signal safety, and real-time queued signals (SIGRTMIN–SIGRTMAX).
• Signal Profiles:
  • POSIX Signals - SIGSEGV: Memory violation, NULL pointer dereferences, and stack overflow handling.
  • POSIX Signals - SIGPIPE: Broken pipe handling across sockets and pipelines.
  • POSIX Signals - SIGHUP: Terminal disconnection, nohup, and daemon hot-configuration reload.
  • POSIX Signals - SIGCHLD: Child process state changes, non-blocking reaping, and zombie prevention.
  • POSIX Signals - SIGTERM: Graceful termination requests and Kubernetes pod lifecycles.
  • POSIX Signals - SIGKILL: Uncatchable process destruction and OOM killer mechanics.
  • POSIX Signals - SIGINT: Terminal keyboard interrupt (Ctrl+C) and foreground process groups.
  • POSIX Signals - SIGBUS: Hardware unaligned memory access and truncated memory-map faults.
  • POSIX Signals - SIGSYS: Bad or restricted system call traps and seccomp sandboxing.

Networking & Socket APIs

• Berkeley Sockets API: Standardizes transport and network layer primitives (socket(), bind(), listen(), accept(), connect(), send(), recv()).
  • Socket Lifecycle Syscalls: Setting up endpoints, listen backlogs, and connection states.
  • Socket I/O Syscalls: Streaming, datagrams, and descriptor passing over SCM_RIGHTS.
  • Socket Options Syscalls: Tuning SO_REUSEADDR, SO_REUSEPORT, and buffer capacities.
• Network Name Resolution: Domain name lookup functions (getaddrinfo(), getnameinfo(), freeaddrinfo()).

System Utilities & Shell Command Language

POSIX defines the exact behavior, options, and exit statuses for command-line execution:

• POSIX Shell Specification: Rules for standard shell grammar (e.g., /bin/sh), subshells, variable expansion, parameter parsing, pipes, and control flow. It strictly excludes non-standard extensions ("bashisms").
• Core Utilities: Standard flags and behaviors for ubiquitous utilities like ls, grep, cd, cat, find, sed, awk, cp, mv, and rm.
• Regular Expressions: Standardized specs for Basic Regular Expressions (BRE) and Extended Regular Expressions (ERE), backed by the C regex library (regcomp(), regexec()).

System Environment & C Library Standard

• C Standard Library Extensions: Extends the ISO C standard with POSIX-specific header files (<unistd.h>, <sys/types.h>, <fcntl.h>, <pthread.h>, <termios.h>).
• Environment & Time Management: Environment variables (PATH, HOME, TZ), process limits (getrlimit, setrlimit), and high-resolution clocks (clock_gettime, nanosleep).
• Locale & Internationalization: Character set definitions, locale environment handling (LC_ALL, LANG), and string transformation APIs (setlocale, iconv).

What POSIX is NOT?

POSIX strictly defines the contract between application programs and the user-space C library/runtime environment—it explicitly avoids defining how the operating system kernel works internally.

What POSIX Defines vs. Ignores

+-------------------------------------------------------------+
|                      User Application                       |
+-------------------------------------------------------------+
                              │
               POSIX Standard Boundary (APIs & Behaviors)
                              │
                              ▼
+-------------------------------------------------------------+
|               C Standard Library (libc / POSIX)             |
|   e.g., pthread_create(), open(), malloc(), printf()       |
+-------------------------------------------------------------+
                              │
              Kernel ABI Boundary (OS-Specific Syscalls)
                              │
                              ▼
+-------------------------------------------------------------+
|                       Kernel Internals                      |
|   (Linux, XNU/macOS, FreeBSD, Illumos, Windows Subsystem)   |
|   - Scheduler logic & thread representations                |
|   - Virtual Memory & Page Table structures                  |
|   - Filesystem layout & disk drivers                        |
|   - System Call numbers and CPU traps                       |
+-------------------------------------------------------------+

What POSIX Defines (User-Facing)

• Function Signatures & Headers: Expects #include <unistd.h>, #include <pthread.h>, and standard signatures like int open(const char *path, int flags, ...).
• Behavioral Expectations: Dictates what happens when a call succeeds or fails (e.g., "If open() fails because the file doesn't exist, set errno to ENOENT").
• Process / Thread Semantics: Defines expected concepts from a programmer's perspective—signals, process IDs (PIDs), file descriptors, standard streams (stdin, stdout, stderr).

What POSIX Ignores (Kernel-Facing)

• System Calls: Does not specify syscall names, numbers, registers, or CPU interrupt instructions.
• Kernel Data Structures: Has no concept of Linux's task_struct, struct page, epoll items, or VFS dentry trees.
• Internal Scheduling: Does not dictate how the kernel scheduler runs threads (e.g., completely fair scheduler vs. round-robin) or whether threads are implemented as kernel tasks, light-weight processes (LWPs), or fiber abstractions.
• Memory Management: Doesn't care how page tables (x86 4-level paging vs. ARM page tables) or page replacement algorithms work inside the MMU.

Real-World Example: Reading a File

When you write POSIX C code:

#include <unistd.h>

ssize_t bytes_read = read(fd, buffer, count);

1. POSIX specifies: read() takes a file descriptor, buffer, and byte count, returning the number of bytes read or -1 on error.
2. Linux implements: glibc issues sys_read (or sys_pread64), jumping into the Linux Virtual File System (VFS), traversing page caches, invoking ext4 or btrfs block drivers, and waking the thread scheduler.
3. macOS implements: libSystem issues a BSD trap into the XNU kernel, invoking APFS (Apple File System) drivers.

Both operating systems are POSIX-compliant, even though their internal kernels, filesystems, and syscall implementations are completely different.

Frequently Asked Questions (FAQ)

Does POSIX define operating system system calls?

No. POSIX standardizes C language library interfaces (System Interfaces), header definitions, and behavioral contracts, explicitly leaving system call numbers, CPU trap instructions, and kernel architectures to individual operating systems. Whether an operating system satisfies read() via a direct monolithic kernel trap, a microkernel IPC message, or a userspace emulation layer does not matter as long as the C function signature, return values, and errno codes conform to the specification.

Is Linux officially POSIX certified?

Most standard Linux distributions are not formally POSIX certified due to the high financial cost of certification, but they largely conform to the standard with numerous non-standard extensions. Operating systems with official POSIX / Single UNIX Specification certifications include Apple macOS, IBM AIX, and HP-UX. Linux provides POSIX compatibility through the GNU C Library (glibc) or musl, while adding performance extensions like epoll, accept4, and io_uring.

What is the difference between POSIX and Single UNIX Specification (SUS)?

The Single UNIX Specification (SUS) is essentially a superset of POSIX maintained by The Open Group that defines what an operating system must implement to officially carry the "UNIX" trademark. Today, POSIX (IEEE Std 1003.1) and SUS (SUSv4) are developed collaboratively as a single unified core standard known as the Austin Group Common Standards.