Daniel Samson
301bdcaf5b
The load-bearing step. The FAT service stops acquiring its own volume: the volume manager spawns it (per volume), defines its partition range on the storage driver BEFORE it runs, and answers its startup hello with the range-confined block channel over a new volume-manager protocol. fat never finds its storage by name and never sees the whole device — establishment by lineage, one layer up from the driver tree. - New library/protocol/volume-manager: one verb, hello(volume-id) -> the block channel as the reply capability (the P0 reply-cap path). - The volume manager becomes the confinement CONTROLLER: it defines the first range on usb-storage, so no other party can confine a filesystem. It supervises the filesystems it spawns and respawns one on death (the reap- and-rebuild the device manager proved, one layer up). - fat: drops acquireVolume(device-manager); hellos the volume manager for its channel; reads its volume id from argv[1]. main takes process.Init now. - init.csv no longer spawns fat (the volume manager does); protocol.csv rewires fat to be supervised by the volume manager (bind vfs, open volume-manager) and drops fat open device-manager. - The block-range fixture boots registry + device-manager only (not the full tree), so the volume manager is absent and the fixture stays the sole confinement definer — otherwise the volume manager would take the controller first and refuse it. Verified end to end (VM probes -> spawns fat -> confines it -> hands over the channel -> fat mounts) and neutral: 18/18 across the fat family, logging, shutdown, both IOMMU variants, usb restart, vfs, conformance, confinement.
1.2 KiB
1.2 KiB
| 1 | # /system/configuration/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 /system/configuration/devices.csv). |
| 13 | # |
| 14 | # service args... |
| 15 | /system/services/input |
| 16 | /system/services/device-manager |
| 17 | # fat is not here: the volume manager spawns one filesystem per volume it finds, |
| 18 | # confined to that volume's partition (docs/file-system-development/storage-architecture.md). |
| 19 | /system/services/volume-manager |
| 20 | /system/services/display |
| 21 | /system/services/display-demo |
| 22 | /system/services/logger |