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.
-
/procMUST be aprocfilesystem exposing the Linux process and kernel interfaces provided by procfs. -
/sysMUST be asysfsfilesystem exposing the Linux kernel object, device, and driver interfaces provided by sysfs. -
/devMUST be adevtmpfsfilesystem exposing device nodes maintained by the Linux kernel. -
/dev/ptsMUST be adevptsfilesystem providing pseudoterminal slave devices. -
/dev/shmMUST be atmpfsfilesystem providing volatile shared-memory storage. -
/runMUST be atmpfsfilesystem providing volatile writable storage for runtime state. -
/tmpMUST be atmpfsfilesystem providing volatile writable storage for temporary data.
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
- Initialization begins with the process as PID 1. The selected read-only root is already established when Initialization begins.
- Initialization does not modify the immutable root filesystem. Writable runtime state MUST be established outside the immutable root filesystem.
-
Kernel interfaces use the standard Linux virtual filesystems.
/procusesprocand/sysusessysfs. -
The kernel maintains the fundamental device namespace.
/devusesdevtmpfs. -
Pseudoterminals use
devpts./dev/ptsMUST provide the pseudoterminal slave namespace throughdevpts. -
Ephemeral writable filesystems use
tmpfs./dev/shm,/run, and/tmpMUST usetmpfsand MUST NOT preserve their contents across system boots. - Compatible inherited state may be reused. The process MUST NOT require runtime filesystems to be recreated solely because they were established by the caller.
- Initialization has an explicit completion boundary. The process MUST NOT consider Initialization complete until every requirement defined by this Specification has been satisfied.
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.