Linux Kernel Architecture Overview and Design Principles

Summary

The Linux kernel’s success stems from a flexible architecture that welcomes many volunteer developers and from highly extensible subsystems, enabling continuous evolution and improvement.

1. Position of the Linux Kernel in a Computer System

The kernel sits in the middle of the system’s layered structure, providing services to higher layers while depending only on lower layers, as illustrated by the dependency principle: upper layers depend on lower ones, but not vice‑versa.

the dependencies between subsystems are from the top down: layers pictured near the top depend on lower layers, but subsystems nearer the bottom do not depend on higher layers.

2. Functions of the Kernel

Virtualization (Abstraction) : abstracts hardware as a virtual machine, offering a virtual interface that user processes can use without knowing hardware details.

Multitasking : arbitrates access to hardware resources so that each process perceives exclusive use of the system.

Process context switching involves swapping program state, page tables, the current task_struct pointer, open files, and the process’s memory space.

3. Overall Kernel Architecture

The central component is the Process Scheduler (SCHED). All other subsystems depend on it because they need to block and resume processes. When a process waits for hardware, the relevant subsystem blocks it; when the hardware completes, the subsystem restores the process via the scheduler.

The scheduler depends on the Memory Manager for allocating memory when a process resumes.

The IPC subsystem relies on the Memory Manager for shared‑memory communication.

The VFS depends on the Network Interface for NFS and on the Memory Manager for ramdisk support.

The Memory Manager depends on the VFS for swapping to disk.

4. Highly Modular Design Facilitates Collaboration

Only a few developers need to work across multiple modules; most work within isolated modules such as hardware device drivers, logical filesystem modules, network device drivers, and network protocol modules, which are the most extensible.

5. Important Data Structures

Task List : the scheduler maintains a list of task_struct instances, forming the task list and a current pointer to the running process.

Memory Map : stored in mm_struct, linking each process’s virtual addresses to physical memory and handling page tables.

Inodes : VFS uses inodes to represent files; each process has a files_struct pointing to its open files.

Data Connections : task_struct also contains pointers to memory maps, open files, and network sockets.

6. Subsystem Architectures

1. Process Scheduler

(1) Goal

The scheduler controls CPU access for all processes and kernel subsystems.

(2) Modules

Scheduling policy module – decides which process gets the CPU.

Architecture‑specific module – abstracts hardware details and performs low‑level blocking/resuming.

Architecture‑independent module – works with the scheduler and memory manager.

System‑call interface – exposes kernel services to user space via POSIX APIs.

(3) Data Representation

The scheduler maintains a task list of task_struct objects, which include state, counters, and pointers accessible throughout the kernel.

(4) Dependencies, Data Flow, Control Flow

The scheduler calls the memory manager to obtain physical pages for resumed processes and is invoked by other subsystems to block or wake processes, creating bidirectional data and control flows across the kernel.

2. Memory Manager

(1) Goal

Manages the mapping between each process’s virtual memory and physical memory, provides protection, and supports swapping.

(2) Modules

Architecture‑specific module – provides hardware‑level memory access.

Architecture‑independent module – handles address translation and swapping.

System‑call interface – offers malloc/free, mmap/umap to user processes.

(3) Data Representation

Mappings are stored in mm_struct, referenced from each task_struct.

(4) Dependencies, Data Flow, Control Flow

On page faults the memory manager receives hardware interrupts, interacts with the file system for swap I/O, and calls the scheduler to block processes while waiting.

3. Virtual File System (VFS)

(1) Goal

Provides a uniform interface to storage devices and supports multiple filesystem types and network filesystems.

(2) Modules

Device driver module

Device‑independent interface

Logical filesystem modules

System‑independent interface

System‑call interface

(3) Data Representation

Files are represented by inodes, which contain pointers to filesystem‑specific operations.

(4) Dependencies, Data Flow, Control Flow

VFS depends on the memory manager for swap and memory‑mapped I/O, on the scheduler to block processes during I/O, and on the network subsystem for network filesystems.

4. Network Interface

(1) Goal

Enables network communication by abstracting hardware devices and protocols.

(2) Modules

Network device drivers

Device‑independent interface

Network protocol modules (TCP, UDP, IP, etc.)

Protocol‑independent interface

System‑call interface for network APIs

(3) Data Representation

Network objects are represented as sockets, which can be shared among processes.

(4) Dependencies, Data Flow, Control Flow

The network subsystem blocks and wakes processes via the scheduler during hardware waits and interacts with VFS for network file systems.

Conclusion

The Linux kernel consists of five major subsystems—process scheduler, memory manager, virtual file system, network interface, and inter‑process communication—interacting through shared data structures and function calls. Its modular, extensible architecture allows many volunteers to contribute efficiently and supports diverse hardware platforms.