Axis / axisd / Initialization

Initialization

Source: initialization_linux.go.

Purpose

This specification defines Initialization, the operation that establishes the minimum runtime environment required for the running Linux system after process entry.

Initialization begins with the process executing as PID 1 and ends when the minimum runtime environment has been established.

Scope

This Specification defines the entry conditions for the process, the minimum runtime filesystems established during Initialization, the handling of compatible state inherited from the caller, the conditions under which Initialization completes, and the behavior required when Initialization cannot complete.

This Specification does not define machine startup, persistent system state, user state, service management, machine-specific support, system transactions, system APIs, application processes, device-management policy, or the initialization of higher-level system components.

The native entry point is initialize() error: nil reports completed initialization; an error describes failure. It returns after setup and does not own the subsequent process lifetime.

Entry Conditions

Initialization accepts a running process, its already established read-only root, and the current mount state. The process must be PID 1; arranging that entry state is the caller’s responsibility.

At the beginning of Initialization, the selected root MUST be a read-only EROFS filesystem and the process MUST be executing as PID 1.

The process MUST verify that it is executing as PID 1 before proceeding with Initialization.

A caller MAY leave compatible runtime filesystems mounted when it transfers execution to the process. If a required runtime filesystem is already mounted with the required filesystem type and behavior, the process MUST keep and use it instead of mounting it again.

Initialization Model

The process initializes the system by ensuring that the minimum kernel interfaces, device interfaces, and ephemeral runtime filesystems required by the running system are available at their defined locations.

Initialization MUST NOT modify the immutable root filesystem.

flowchart TD
    Entry["Process entry"]
    Process["PID 1 process"]
    Kernel["Kernel interfaces"]
    Devices["Device interfaces"]
    Ephemeral["Ephemeral runtime state"]
    Runtime["runtime"]

    Entry -->|enters| Process
    Process -->|establishes| Kernel
    Process -->|establishes| Devices
    Process -->|establishes| Ephemeral
    Kernel --> Runtime
    Devices --> Runtime
    Ephemeral --> Runtime

    class Process program

Runtime Filesystems

During Initialization, the process MUST ensure that the runtime filesystems defined by this section are mounted with the required filesystem types and semantics.

The contents of /dev/shm, /run, and /tmp MUST NOT persist across system boots.

Device Filesystem

The kernel-maintained device nodes exposed through devtmpfs form the fundamental device namespace of the system.

The immutable root supplies the /dev mount point without device nodes. Initialization establishes devtmpfs; the kernel then maintains the device namespace.

The process MUST NOT require a userspace device manager to create the fundamental device nodes required for Initialization.

Device-management policy performed after device nodes exist, including permissions, ownership, stable names, symbolic links, reactions to device events, and other higher-level device behavior, is outside the scope of this Specification.

The use of devtmpfs does not preclude the system from providing additional device-management behavior through later runtime services.

Inherited Runtime State

A caller MAY leave runtime filesystems mounted when execution is transferred to the process.

The process MUST reuse an inherited mount when that mount already satisfies the filesystem type and semantics required by this Specification for its location.

If an inherited mount does not satisfy the applicable requirement, the process MUST establish a conforming runtime filesystem before Initialization can complete.

Whether a runtime filesystem was established by the caller or by the process MUST NOT change its semantics during the runtime.

Completion

Initialization completes when the process is executing as PID 1 and all runtime filesystems required by this Specification have been successfully established.

Completion of Initialization marks the beginning of normal runtime management by the process.

Initialization completion does not imply that persistent state, machine-specific support, users, services, networking, device-management policy, applications, or other higher-level system facilities have been initialized unless explicitly implemented as a separate runtime facility.

flowchart LR
    Entry["PID 1 process"]
    Kernel["Kernel interfaces"]
    Devices["Device interfaces"]
    Ephemeral["Ephemeral state"]
    Initialized["Initialization complete"]
    Runtime["Runtime management"]

    Entry --> Kernel
    Kernel --> Devices
    Devices --> Ephemeral
    Ephemeral --> Initialized
    Initialized --> Runtime

    class Entry program

Failure

Initialization MUST fail if the process is not executing as PID 1.

Initialization MUST fail if a runtime filesystem required by this Specification cannot be established with the required filesystem type and semantics.

The process MUST NOT report Initialization as complete while any mandatory Initialization requirement remains unsatisfied.

The behavior of the system after Initialization failure, including diagnostics, recovery, shutdown, or restart, is outside the scope of this Specification.

Fundamental Invariants

Conformance

An implementation conforms to this Specification when the process begins Initialization as PID 1 with the immutable root filesystem already established, establishes or validates all required runtime filesystems with the required filesystem types and semantics without modifying the immutable root filesystem, and returns success only after all Initialization requirements have been satisfied.