Files
danos/etc/init.csv
T
danielandClaude Opus 4.8 081ba1d74e init: data-driven boot service list via /etc/init.csv
Replace init's hardcoded boot_services array with an authoritative,
human-readable service list read at boot, mirroring /etc/devices.csv. Each row
is a service binary path followed by its argv; startup order is file order,
shutdown the reverse. There is no hardcoded fallback — a missing file starts
nothing (the no-ramdisk isolation behavior).

- library/csv: shared CSV helpers (comment strip, field iteration) with unit
  tests; device-registry is refactored onto them so both /etc/*.csv files parse
  through one place.
- init reads /etc/init.csv into fixed-max static tables (the same pattern as the
  device registry) and passes each row's argv straight to spawnSupervised. This
  also makes boot-time modes (e.g. device-manager test-usb-restart) expressible
  as data rather than hardcoded.
- Diagnose mode (-Ddiagnose omits the display stack) becomes build-time file
  selection between etc/init.csv and etc/init-diagnose.csv, so init carries no
  comptime service logic; the diagnose build option is dropped from init.
- build.zig: csv module wired; /etc/init.csv bundled into the initrd; the
  device-registry tests move to a dedicated block since they now import csv.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KJqSiLLchDUUCoXn5jsiwd
2026-07-26 17:13:51 +01:00

963 B

1# /etc/init.csv — the services init (PID 1) starts at boot, in order.
2#
3# init reads this at startup and spawns each service supervised (restarting it on
4# a crash, up to a cap). Startup order is top->bottom; shutdown is the reverse, so
5# the logger (last) goes down first and its final drain still has the fat server
6# and the whole storage chain alive underneath it. It is AUTHORITATIVE — there is
7# no hardcoded fallback list; a missing file means no services are started.
8#
9# '#' starts a comment (whole-line or trailing); blank lines are ignored. The
10# first field is the service binary path; any fields after it are the service's
11# argv. Drivers are absent on purpose — the device manager discovers hardware and
12# spawns those (see /etc/devices.csv).
13#
14# service args...
15/system/services/input
16/system/services/device-manager
17/system/services/fat
18/system/services/display
19/system/services/display-demo
20/system/services/logger