danos/system/services/init
Daniel Samson 56110b0019
Device manager (increment 3): the kernel stops spawning the bundle
Retire the kernel's spawn-every-initial-ramdisk-binary loop, resolving the
service/driver split into a real three-level supervision hierarchy:

  kernel  -> spawns init (PID 1) only, and publishes the initial-ramdisk
  init    -> the service supervisor: spawns the system services (vfs, device-manager)
  device-manager -> spawns the drivers it matches (hpet)

The kernel now only hands the initial-ramdisk image to the process layer
(publishInitialRamdisk) so user space can system_spawn from it; it launches nothing
bundled itself. init gains a boot-services list ("vfs", "device-manager") and spawns
them best-effort before settling into its heartbeat — policy lives in user space,
where a microkernel keeps it. Drivers are absent from that list on purpose: the
device manager owns them. Test-only binaries (vfs-test, bus) no longer run at boot;
their kernel self-tests still spawn them directly.

This removes increment 2's transitional double-spawn: a real boot now brings hpet up
exactly once (verified — kernel -> init -> vfs/device-manager -> hpet, zero "claim
failed"). The automated suite is unaffected: test builds run their case and halt
before the normal boot path, so each already spawns its own binaries. Suite 36/36
plus host tests; normal boot verified by hand under QEMU.
2026-07-10 18:36:07 +01:00
..
init.zig Device manager (increment 3): the kernel stops spawning the bundle 2026-07-10 18:36:07 +01:00