EriX Root Task (rootd)

rootd is the first user-space policy authority launched by kernel. It receives the kernel -> root handoff and bootstraps critical early services.

---

Scope

• validate kernel bootstrap info and capability inventory
• parse required boot-config payload and establish deterministic launch DAG
• transfer least-privilege capabilities to each service
• track bootstrap readiness and fail deterministically on required-service errors

Out of Scope

• low-level kernel object implementation
• implicit authority distribution

---

Service Bring-up Responsibilities

rootd launches services according to boot-config DAG entries. The current runtime baseline still resolves to:

• foundation substrate: memd -> vspaced -> pagerd -> procd
• coordination core: named -> logd -> crashd -> timed
• hardware mediation core: irqd -> deviced -> probed -> hotplugd
• console/input stack: seriald -> fbcond -> inputd

After procd is up, subsequent services are spawned through the typed procd service-spawn API (IPC_PHASE0_PROCD_OP_SPAWN_SERVICE), not by direct kernel process creation from rootd.

Driver daemons are owned by deviced; rootd requests driver lifecycle through deviced RPCs. BOOTCFG_LAUNCH_KIND_DEVICED_DRIVER entries are treated as policy nodes (seed/seal intent), not synchronous rootd wait points.

---

Interfaces

• input: docs/handoff/kernel-to-root.md
• output: docs/handoff/root-to-services.md
• shared wire/layout helpers: lib-handoff

---

Invariants

• no service receives undeclared authority
• required-service startup failures halt bootstrap progression
• startup IPC and capability transfer are auditable and deterministic
• framebuffer-mode bootstrap requires both fbcond and console-font module inputs
• missing/invalid boot-config is fail-closed
• rootd attempts capability shedding checkpoints:
  • after procd readiness: untyped drop sweep and transfer of kernel-object management copies to procd/deviced
  • after deviced readiness: device-control slot drop (SLOT_IRQ_CONTROL)
• rootd does not emit driver-ready stamps; driver-ready observability is emitted by deviced (ERIX_DEVICED:READY:*).

---

Build Status

Implemented M0 baseline:

• no_std root task binary with x86_64 SysV entry ABI:
  • rdi = kernel_root_handoff_ptr
  • rsi = kernel_root_handoff_size
  • rdx = root_endpoint_slot
• strict kernel -> root handoff intake validation (lib-handoff parser + descriptor checks)
• deterministic rootd status model (READY, HANDOFF_INVALID, CONTRACT_INVALID, INTERNAL_ERROR, SERVICE_BOOTSTRAP_FAILED)
• required boot-config discovery and v1 parse/validate path (ERIXBCFG)
• config-driven async dependency startup event loop
• launch dispatch by launch_kind:
  • rootd direct service startup
  • deviced-managed driver startup (START_DRIVER)
• feature-gated integration reporting path:
  • runtime bootstrap path uses one binary and consumes boot-config validation_profile (none for runtime image builds, phase profile IDs for smoke/integration scenario builds)
  • compatibility smoke aliases: rootd-integration-* map to runtime phase features
  • force-fail controls remain integration-only:
  • rootd-integration-smoke
  • rootd-integration-force-fail
  • rootd-integration-force-service-fail
  • rootd-integration-force-spawn-fail

Implemented Phase0 orchestration baseline:

• deterministic required module discovery for memd, vspaced, pagerd, procd, and phase0-probe
• deterministic service launch-order state machine:
  • intake validated
  • module set discovered
  • per-service (memd -> vspaced -> pagerd -> procd) startup-envelope synthesis/validation
  • probe spawn request contract synthesis/validation
• role-based startup envelope generation using lib-bootstrap + lib-capabi transfer bundle validation
• integration stage progress reporting (ROOTD_STAGE:*) via feature-gated rootd-report syscall path

Runtime-oriented bring-up path:

• service launch requests issued through kernel-control IPC (CREATE_PROCESS, REGISTER_PAGER, MAP_FRAME, START_PROCESS)
• per-service startup envelope delivery and readiness handshake over endpoint CALL/REPLY
• probe spawn request via procd plus async probe-completion event wait on the root endpoint before reporting READY

Current runtime-mode policy:

• runtime builds are bootstrap-only (no synthetic probe/client/stress execution)
• smoke/integration builds retain synthetic checks for CI verification
• phase3-framebuffer bootstrap fails closed if console-font is not present
• phase3-input bootstrap requires drv-i8042, drv-ps2-kbd, drv-ps2-mouse, and inputd