Boot Process and Init

Relevant source files

The following files were used as context for generating this wiki page:

• Documentation/process/howto.rst
• Documentation/kernel-hacking/hacking.rst
• Documentation/process/4.Coding.rst
• Documentation/process/submitting-patches.rst
• Documentation/admin-guide/kernel-parameters.rst
• init/main.c
• init/initramfs.c

The Linux boot process transforms the system from a powered-off state to a fully functional operating environment. The kernel initializes hardware, sets up core subsystems, and executes the first user-space process. This phase is critical for establishing the freestanding C environment used by the kernel.

Kernel Initialization Phase

The kernel starts in a freestanding C environment. It does not rely on standard C libraries. During early boot, the kernel configures the memory management unit (MMU) and architectural specific components.

Memory and Subsystem Setup

The kernel uses specialized routines to manage memory before the standard allocators are active.

• alloc_bootmem(): Allocates large physically contiguous memory blocks early in the boot process.
• kmalloc(): Becomes available later for dynamic pointer-aligned chunks.
• __init: Marks functions for removal from memory after the boot process completes.

Sources: Documentation/kernel-hacking/hacking.rst:248-257, Documentation/kernel-hacking/hacking.rst:328-335

Boot Parameters

Kernel parameters control behavior during the initialization phase. These are defined in the bootloader and processed by the kernel.

• Users can modify hardware detection or subsystem behavior via these strings.
• Parameters are documented in Documentation/admin-guide/kernel-parameters.rst.

Sources: Documentation/process/4.Coding.rst:323-326, Documentation/process/howto.rst:111-115

The Init Process

The transition from kernel space to user space occurs when the kernel executes the init process. This is the first process in the system and the ancestor of all other processes.

Module Initialization

The kernel provides macros to handle both built-in and modular code initialization.

• module_init(): Defines the function called at boot time for built-in code or at insertion time for modules.
• __initcall(): The internal equivalent for built-in initialization used by module_init().

The diagram shows the transition from low-level kernel initialization to the execution of the first user-space process.

Sources: Documentation/kernel-hacking/hacking.rst:341-351, Documentation/kernel-hacking/hacking.rst:49-55

Execution Contexts During Boot

The kernel operates in different contexts during the boot sequence. Understanding these is vital for avoiding deadlocks and system crashes.

User Context

During module_init(), the kernel runs in user context with interrupts enabled. This allows the initialization code to sleep or perform blocking operations.

Interrupt Context

Hardware interrupts (Hard IRQs) can occur once enabled. These service hardware like timers and network cards. Interrupt handlers must be fast and cannot sleep.

Context	Can Sleep	Description
User Context	Yes	Coming from a system call or module_init.
Hard IRQ	No	Servicing hardware interrupts.
Softirq / Tasklet	No	Deferred interrupt work.

Sources: Documentation/kernel-hacking/hacking.rst:33-100, Documentation/kernel-hacking/hacking.rst:162-175

Summary

The boot process begins with hardware-specific initialization and progresses through subsystem setup using __init marked code. The kernel processes boot parameters to configure specific behaviors before executing the first user-space process via module_init mechanisms. Proper management of execution contexts and memory allocation routines ensures system stability during this transition.