Architecture

Linux is a monolithic kernel with loadable modules. Every subsystem runs in the same address space and can call directly into any other. The kernel speaks to user space through a stable set of system calls and through file-system-like interfaces (/proc, /sys, debugfs, bpf, io_uring, etc.). Loadable kernel modules (*.ko) extend the kernel without rebuilding it.

High-level layering

graph TD
    UA[User-space programs and libc]
    SC[System call interface<br/>arch/&lt;arch&gt;/entry, kernel/sys.c]
    CORE[Core subsystems<br/>kernel/, mm/, ipc/, security/]
    IO[I/O subsystems<br/>fs/, block/, io_uring/, net/, sound/]
    HW[Hardware abstraction<br/>arch/, drivers/, virt/]
    RUST[Rust glue<br/>rust/]
    UA -->|syscalls, ioctls| SC
    SC --> CORE
    CORE --> IO
    CORE --> HW
    IO --> HW
    RUST -.linked into.-> CORE
    RUST -.linked into.-> HW

• User-space programs invoke system calls (read, mmap, clone3, io_uring_enter, etc.). Architecture-specific entry code (e.g. arch/x86/entry/) handles the trap, switches to kernel mode, and dispatches into the generic syscall table defined in kernel/sys.c and per-subsystem files.
• Core subsystems (kernel/, mm/, ipc/, security/) provide scheduling, memory management, IPC, and security policy.
• I/O subsystems (fs/, block/, io_uring/, net/, sound/) implement files, networks, and audio.
• Hardware support is split between architecture-neutral drivers (drivers/) and architecture-specific code (arch/). Virtualization host code lives in virt/.
• Rust code under rust/ is compiled and linked into the same binary; it does not run in a separate context.

Top-level source tree

The repository root (see README) contains these directories:

Directory	Purpose	Wiki page
arch/	Per-architecture code (boot, traps, atomics, memory, syscalls)	Architecture support
block/	Block-device layer, multi-queue I/O scheduler, blk-cgroup	Block layer
certs/	Module signing and platform key infrastructure	Certs
crypto/	Crypto API, ciphers, hashes, AEAD, asymmetric keys	Crypto
drivers/	The bulk of the tree: device drivers for everything	Drivers
fs/	VFS and concrete file systems (ext4, btrfs, xfs, …)	Filesystems
include/	Public kernel headers and UAPI headers	Include
init/	Boot-time start_kernel(), initramfs, version stamping	Init
io_uring/	The io_uring asynchronous I/O subsystem	io_uring
ipc/	System V IPC (msg queues, semaphores, shared memory)	IPC
kernel/	Scheduler, locking, RCU, BPF, cgroup, time, futex, tracing	Kernel core and Scheduler
lib/	Library helpers shared across the kernel	Lib
mm/	Memory management: page allocator, slab, vmalloc, swap, DAMON	Memory management
net/	Networking: sockets, IPv4/IPv6, netfilter, eBPF networking	Networking
rust/	Rust runtime, kernel crate, bindings, pin-init	Rust support
samples/	In-tree example modules and BPF programs	Samples
scripts/	Build helpers, kconfig parser, checkpatch, linker scripts	Scripts
security/	LSM framework, SELinux, AppArmor, Smack, IMA, keyrings	Security
sound/	ALSA core, sound drivers, ASoC	Sound
tools/	Userspace tools (perf, bpftool, libbpf, selftests)	Tools
usr/	Initramfs generator (cpio image embedded in the kernel)	usr
virt/	Hypervisor host code (KVM common parts)	Virtualization

Build flow

graph LR
    KCONFIG[Kconfig + .config] -->|expanded by| Kbuild
    SRC[*.c, *.S, *.rs] --> Kbuild[Kbuild Makefiles]
    Kbuild --> CC[Compile to .o]
    CC --> LINK[Link vmlinux]
    LINK --> COMPRESS[bzImage / Image / vmlinuz]
    Kbuild --> MOD[Loadable modules .ko]
    Kbuild --> DTS[Device-tree blobs]

Every directory in the tree contains a Makefile describing what it compiles. The top-level Makefile drives Kbuild, which is the kernel's recursive make system. Configuration is captured in Kconfig files and materialized into a .config file before the build. The output is vmlinux (the statically linked kernel), compressed boot images per architecture, kernel modules, and device-tree blobs.

For more on Kbuild and Kconfig, see Subsystems → Scripts and Reference → Configuration.

Boot flow

graph TD
    BL[Bootloader] -->|hands off| ARCH_HEAD[arch/<arch>/kernel/head_*]
    ARCH_HEAD -->|sets up MMU, decompresses| START[start_kernel in init/main.c]
    START --> EARLY[Early subsystem init]
    EARLY --> RCU[RCU + scheduler online]
    RCU --> INITCALLS[do_initcalls: subsystems register]
    INITCALLS --> MOUNT[Mount initramfs from usr/]
    MOUNT --> EXEC_INIT[exec /init or /sbin/init]

After the architecture-specific assembly stub is done, control transfers to start_kernel() in init/main.c. start_kernel() brings up traps, memory, scheduler, RCU, then runs the initcall chain that lets every other subsystem register itself, mounts the initramfs (usr/), and finally execs PID 1.

Cross-cutting subsystems

Several systems are not "just one directory" but live across many areas of the tree:

• eBPF: kernel/bpf/, net/core/filter.c, net/bpf/, tools/bpf/, tools/lib/bpf/, plus per-driver attach points. Documented under Kernel core and Networking.
• Tracing: kernel/trace/, include/trace/, ftrace and tracepoints sprinkled across drivers.
• Cgroups: kernel/cgroup/, plus per-resource controllers in block/blk-cgroup.c, mm/memcontrol.c, net/core/netclassid_cgroup.c, etc.
• Power management: kernel/power/, drivers/cpufreq/, drivers/cpuidle/, drivers/base/power/.
• Device model: drivers/base/, plus per-bus directories (drivers/pci/, drivers/usb/core/, etc.).
• Locking primitives: declared in include/linux/, implemented in kernel/locking/, with arch fast-paths in arch/.

Address space and concurrency model

• The kernel runs in its own address space (kernel half of the virtual address space). Every thread has a kernel stack used while servicing syscalls or interrupts.
• Concurrency is fine-grained. The kernel uses spinlocks (spinlock_t), mutexes (struct mutex), reader-writer locks (rwlock_t, seqlock_t), and read-copy-update (rcu_read_lock etc.) extensively. Each subsystem documents which locks protect what.
• Preemption can be configured (voluntary, preemptible, RT). See kernel/Kconfig.preempt.
• Interrupt handling is split between hardirq context (top half) and softirq/tasklet/threaded handlers (bottom half). NMI handlers exist for select paths.

Stable interfaces

The user-space ABI is stable; the in-kernel APIs are not. See Documentation/process/stable-api-nonsense.rst for the canonical statement on this. UAPI headers live under include/uapi/ and are exported to user space.