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.
23 lines
1.2 KiB
CSV
23 lines
1.2 KiB
CSV
# /system/configuration/init.csv — the services init (PID 1) starts at boot, in order.
|
|
#
|
|
# init reads this at startup and spawns each service supervised (restarting it on
|
|
# a crash, up to a cap). Startup order is top->bottom; shutdown is the reverse, so
|
|
# the logger (last) goes down first and its final drain still has the fat server
|
|
# and the whole storage chain alive underneath it. It is AUTHORITATIVE — there is
|
|
# no hardcoded fallback list; a missing file means no services are started.
|
|
#
|
|
# '#' starts a comment (whole-line or trailing); blank lines are ignored. The
|
|
# first field is the service binary path; any fields after it are the service's
|
|
# argv. Drivers are absent on purpose — the device manager discovers hardware and
|
|
# spawns those (see /system/configuration/devices.csv).
|
|
#
|
|
# service args...
|
|
/system/services/input
|
|
/system/services/device-manager
|
|
# fat is not here: the volume manager spawns one filesystem per volume it finds,
|
|
# confined to that volume's partition (docs/file-system-development/storage-architecture.md).
|
|
/system/services/volume-manager
|
|
/system/services/display
|
|
/system/services/display-demo
|
|
/system/services/logger
|