The Linux kernel is one of the largest collaborative software projects in human history. As of 2024, it comprises over 30 million lines of code, contributed by tens of thousands of developers across three decades. Yet despite this scale, the source tree is remarkably well-organized—a testament to disciplined engineering and Linus Torvalds' insistence on maintainability.

For anyone seeking to understand Linux internals, contribute patches, write drivers, or debug production issues, understanding the source layout is essential. This page provides a comprehensive map of the kernel source tree, explaining not just where things are, but why they're organized that way.

When you extract or clone the Linux kernel source (git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git), you'll find approximately 20 top-level directories. Each has a specific purpose and contains related functionality.

Obtaining the Source:

# Clone the official repository (full history, ~4GB)
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

# Or download a specific release tarball
wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.xz
tar -xf linux-6.6.tar.xz

Let's examine what you'll find:

The arch/ directory contains code specific to each processor architecture Linux supports. This is where the kernel interfaces with the bare metal—boot sequences, interrupt handling, context switching, memory management unit configuration, and system call entry points.

Supported Architectures (as of Linux 6.x):

Structure of arch/x86/ (the most common architecture):

arch/x86/
├── boot/               # Bootloader interface, compressed kernel setup
│   ├── compressed/     # Decompression code for vmlinuz
│   └── tools/          # Build tools for boot image
├── entry/              # System call & interrupt entry points
│   ├── entry_64.S      # 64-bit syscall entry (assembly)
│   └── common.c        # Common entry code
├── include/            # x86-specific headers
│   ├── asm/            # Architecture-specific asm/ headers
│   └── uapi/           # Userspace-visible definitions
├── kernel/             # x86 core kernel
│   ├── cpu/            # CPU feature detection, microcode
│   ├── process.c       # Context switching
│   ├── signal.c        # Signal handling
│   └── setup.c         # Early boot setup
├── mm/                 # x86 memory management
│   ├── pgtable.c       # Page table manipulation
│   ├── fault.c         # Page fault handling
│   └── tlb.c           # TLB flush operations
├── kvm/                # KVM virtualization (x86-specific)
├── platform/           # Platform-specific (Chrome, Surface, etc.)
└── Makefile            # Build rules for x86

Key Files to Understand:

• arch/x86/entry/entry_64.S: The assembly code for 64-bit system call entry. Every system call passes through here. Understanding this file reveals how user-space transitions to kernel-space.

• arch/x86/kernel/process_64.c: Contains __switch_to(), the context switch implementation. Shows how the kernel saves and restores CPU state.

• arch/x86/mm/fault.c: Page fault handler for x86. Called when a memory access triggers a fault—key for understanding demand paging and copy-on-write.

• arch/x86/boot/header.S: The very first code executed when the kernel boots (after the bootloader). Sets up protected mode and jumps to C code.

The kernel/ directory contains architecture-independent core kernel functionality—the heart of what makes Linux an operating system. This is where scheduling, process management, signals, time management, and tracing live.

Key Subdirectories and Files:

Deep Dive: The Scheduler (kernel/sched/)

The scheduler is arguably the most critical subsystem. Let's examine its organization:

1. core.c (~8,000 lines): The heart of scheduling. Contains schedule(), which is called whenever the kernel needs to pick the next task to run. Also contains context_switch(), load balancing, and CPU hotplug handling.

2. fair.c (~12,000 lines): The Completely Fair Scheduler (CFS), Linux's default. Implements a red-black tree of runnable processes ordered by virtual runtime, ensuring fairness over time.

3. rt.c (~2,500 lines): Real-time scheduling classes SCHED_FIFO (first-in-first-out, runs until it yields) and SCHED_RR (round-robin with time slices).

4. deadline.c (~2,500 lines): SCHED_DEADLINE, an Earliest Deadline First scheduler for hard real-time tasks.

5. idle.c: The idle task—what the CPU runs when there's nothing else to do. Manages power-saving states (C-states).

The mm/ directory contains Linux's sophisticated memory management subsystem—one of the most complex and performance-critical parts of the kernel. It handles everything from allocating single pages to managing terabytes of RAM with NUMA awareness.

Core Components:

Memory Allocation Layers:

Linux has multiple allocation layers, each serving different needs:

                    User Space
                        ↓
        ┌───────────────────────────────┐
        │       malloc()/mmap()         │  ← C library
        └───────────────┬───────────────┘
                        ↓ System Call
        ┌───────────────────────────────┐
        │     sys_brk() / sys_mmap()    │  ← VMA layer (mm/mmap.c)
        │       Virtual Memory Areas    │
        └───────────────┬───────────────┘
                        ↓ Page Fault
        ┌───────────────────────────────┐
        │    handle_mm_fault()          │  ← Page table management
        │    Page Table Manipulation    │     (mm/memory.c)
        └───────────────┬───────────────┘
                        ↓
        ┌───────────────────────────────┐
        │    Slab Allocator (SLUB)      │  ← Object caching
        │    kmalloc(), kmem_cache_*    │     (mm/slub.c)
        └───────────────┬───────────────┘
                        ↓
        ┌───────────────────────────────┐
        │    Buddy Allocator            │  ← Physical pages
        │    alloc_pages(), free_pages  │     (mm/page_alloc.c)
        └───────────────┬───────────────┘
                        ↓
        ┌───────────────────────────────┐
        │    Physical Memory (RAM)      │
        └───────────────────────────────┘

The fs/ directory contains the Virtual File System (VFS) layer and implementations of numerous file systems. VFS provides the unified interface that allows operations like open(), read(), and write() to work consistently across ext4, XFS, NFS, and dozens of other file systems.

VFS Core Files:

VFS Object Model:

VFS defines four fundamental object types that file systems must implement:

1. Superblock (struct super_block): Represents a mounted file system. Contains file system metadata like block size, max file size, and mount options. Each mount has one superblock.

2. Inode (struct inode): Represents a file on disk. Contains metadata (permissions, timestamps, size) and operation pointers. Inodes are cached in memory for performance.

3. Dentry (struct dentry): Represents a directory entry—a (name, inode) pair. Dentries form the directory cache (dcache), dramatically speeding path lookups.

4. File (struct file): Represents an open file descriptor. Contains the current position, open flags, and pointers to operations. Multiple file structs can point to the same inode.

Operation Vectors:

Each object type has an associated operations structure (function pointer table):

• struct super_operations — Superblock operations (sync, inode allocation)
• struct inode_operations — Inode operations (create, lookup, link)
• struct file_operations — File operations (read, write, mmap, ioctl)
• struct dentry_operations — Dentry operations (compare, delete)

The drivers/ directory is by far the largest in the kernel, comprising over 55% of all source code. This reflects Linux's extraordinary hardware support—if a device exists, there's probably a Linux driver for it.

Organization by Device Class:

Driver Model:

Linux has a unified driver model centered on buses, devices, and drivers:

// drivers/base/bus.c, driver.c, device.c

struct bus_type {
    const char *name;           // "pci", "usb", "platform"
    int (*match)(struct device *, struct device_driver *);
    int (*probe)(struct device *);
    // ...
};

struct device_driver {
    const char *name;
    struct bus_type *bus;
    int (*probe)(struct device *);
    void (*remove)(struct device *);
    // ...
};

struct device {
    struct device *parent;
    struct bus_type *bus;
    struct device_driver *driver;
    // ...
};

Registration Flow:

1. Bus registers with the driver core (bus_register())
2. Driver registers with its bus (driver_register())
3. Device is discovered (enumeration, hot-plug)
4. Bus matches device with driver (bus->match())
5. Driver's probe function is called (driver->probe())
6. Driver initializes hardware, registers device nodes

The net/ directory contains Linux's complete networking stack—one of the most mature and performant in existence. It handles everything from TCP/IP to Bluetooth to packet filtering.

Major Subsystems:

The Socket Buffer (SKB):

The fundamental data structure for networking is struct sk_buff, defined in include/linux/skbuff.h. Every network packet—incoming or outgoing—is wrapped in an SKB:

struct sk_buff {
    struct sk_buff *next, *prev;     // Queue links
    struct sock *sk;                  // Owning socket
    struct net_device *dev;           // Associated device
    
    unsigned char *head;              // Buffer start
    unsigned char *data;              // Payload start (moves through layers)
    unsigned char *tail;              // Payload end
    unsigned char *end;               // Buffer end
    
    unsigned int len;                 // Packet length
    unsigned int data_len;            // Data fragments length
    
    __u16 protocol;                   // Packet protocol
    __u16 transport_header;           // Offset to L4 header
    __u16 network_header;             // Offset to L3 header
    __u16 mac_header;                 // Offset to L2 header
    // ... many more fields
};

As packets traverse the network stack, the data pointer is adjusted to point to the current layer's header—a clever design that avoids copying.

Several directories support the kernel build process and development workflow:

scripts/ - Build Tools and Development Utilities:

Kconfig Files:

Every directory contains a Kconfig file defining configuration options for that subsystem:

# Example from drivers/net/Kconfig

menuconfig NET_ETHERNET
    bool "Ethernet device support"
    depends on NET
    help
      Enable support for Ethernet devices.

config E1000E
    tristate "Intel(R) PRO/1000 PCI-Express Gigabit"
    depends on PCI && NET_ETHERNET
    help
      This driver supports Intel PRO/1000 adapters.
      
      To compile as a module, choose M. The module
      will be called e1000e.

Kconfig defines the options you see in make menuconfig. Note tristate—can be Y (built-in), M (module), or N (not compiled).

Makefile Structure:

Kernel Makefiles use a specialized syntax. Example from drivers/net/ethernet/intel/e1000e/:

# Conditional compilation based on config
obj-$(CONFIG_E1000E) += e1000e.o

# Multi-file module
e1000e-objs := netdev.o ethtool.o param.o hw.o

# Compiler flags specific to this directory  
ccflags-y += -I$(srctree)/drivers/net/ethernet/intel

The obj-$(CONFIG_...) pattern ensures files are only compiled if configured.

With 30+ million lines of code, effective navigation tools are essential. Here are the tools and techniques used by kernel developers:

What's Next:

With the source structure mapped, we'll explore Kernel Configuration—how to navigate the thousands of options, understand what they do, and build a kernel tailored to your needs.