Skip to content
Linux Systems Field Manual

Boot, Init, And Process Model

Imported from _research/manual-study-linux/boot-init-process.md.

Boot, Init, And Process Model

Status: implemented source-backed volume.

Source Surface

  • init/main.c: kernel entry sequencing from start_kernel() to init.
  • kernel/fork.c: process/task creation, already covered in the scheduler volume as the task lifecycle constructor.

Entry Points

init/main.c declares kernel_init near line 122. The central boot function is start_kernel() at line 972. After early setup, it reaches rest_init() at line 1175, which creates the first kernel threads and hands control toward the ordinary scheduler-driven world.

kernel_init() appears around line 1539 and kernel_init_freeable() around line 1629. This split matters: early boot has one set of constraints, while later init can release init memory and run broader setup.

Boot Ordering

start_kernel() is a global dependency-ordering function. It initializes memory and VFS caches, tracing, scheduling, RCU, console, and other core subsystems in a deliberate order. Notable calls include:

  • mm_core_init_early() around line 995.
  • vfs_caches_init_early() around line 1031.
  • mm_core_init() around line 1034.
  • ftrace_init() around line 1037.
  • early_trace_init() around line 1040.
  • sched_init() around line 1047.
  • rcu_init() around line 1067.
  • trace_init() around line 1071.
  • srcu_init() around line 1083.
  • console_init() around line 1112.
  • vfs_caches_init() around line 1157.

do_basic_setup() at line 1438 and driver_init() at line 1442 move from core kernel setup into driver/subsystem initialization.

Process Handoff

Linux boot is not one monolithic “main”. It is a staged handoff:

  1. Architecture code enters generic kernel setup.
  2. Core global subsystems are initialized before general concurrency exists.
  3. Scheduler, RCU, timers, and tracing become available.
  4. Kernel threads and init process are created.
  5. Initcalls and driver setup expand the system.
  6. User-space init eventually becomes responsible for policy.

Rust Translation

A Rust kernel should model boot as explicit initialization phases:

  • EarlyBoot: no allocator or concurrency assumptions unless proven.
  • CoreInit: memory, scheduler, time, and logging become available.
  • DriverInit: buses and devices can probe.
  • UserspaceHandoff: init task and process model are live.

Subsystem APIs should state which boot phase they require.

AI-Native Translation

AI runtimes need the same staged startup discipline. Do not start agents before identity, storage, policy, telemetry, resource accounting, and cancellation are initialized. Boot phases should be auditable, replayable, and failure-aware.

  • file-notes/linux__init__main.c.md
  • file-notes/linux__kernel__fork.c.md