Daniel Samson
a2d6056772
The first driver to stop claiming its own hardware. The device manager holds the controller and transfers it in the hello reply, so its matching becomes authoritative instead of advisory — until now the driver claimed the id it found in argv[1], and any process could have claimed the same integer first. The manager claims before it spawns, so there is no window in which anything else could take the device, and transfers in onHello using invocation.sender — the kernel-stamped task id, which cannot be forged by the caller. hello is synchronous, so the transfer has completed before the reply lands: no gap between being told yes and holding the thing. usb-xhci-bus's hello moves from after controller bring-up to before anything that needs the device, which is the bring-up reorder the design predicted. It is the first member of an explicit delegated set, so every unconverted driver keeps claiming exactly as before and the suite stays green; the set and device_claim both go at D6. D3 and D4 could not be separated and the plan records why: the moment the manager claims, any driver still calling device_claim is refused, and D3 applied to nothing changes no behaviour and cannot be tested. This step introduced a regression and the incremental conversion is what caught it. confineDevice runs inside systemDeviceClaim, so a device arriving by transfer was never confined for its new owner. Three IOMMU+USB cases failed on the driver's DMA rings going unbound, and two worse consequences were latent: a manager death would have torn down a domain a live driver was using, and a driver death would have leaked one. iommu.reassign now moves the confinement with the device, keeping the domain and its attachment intact so it never translates through nothing. Converting all five drivers at once would have produced the same three failures with five suspects. A log line of mine claimed "holding controller device N" before anything verified it — it printed even in the failure case, where the driver held nothing. Reworded to state only what is known there: where the registers are. usb-hid asserts the delegation with the device id backreferenced, so the id delegated and the id the driver ends up with must match. Emptying the delegated set fails it with "hello acknowledged" then "mmio_map failed". usb-hub failed once in a full run and has passed six times since (four isolated, two full) — recorded in the plan as a suspected instance of the known intermittent AP fault, not dismissed, since this step did shift boot timing. Suite 118/118.
DanOS
Codename: Shodan
A very small resilient operating system.
Zen of DanOS:
- Resilient Micro-Kernel Architecture.
- Every process run in an isolated user space not kernel space.
- Processes cannot take down the entire OS with it when they die or is killed
- Stable public runtime library, private OS ABI.
- Keeps a stable runtime for user space processes between OS versions (great for backwards compatibility)
- Allows the underlying OS to be changed without effecting applications
- Provides a boundary to enable compatibility between OS's e.g. POSIX, MUSL etc
- Drivers are just isolated processes in user space.
- Thin binaries that can be restarted like applications.
- Useful during driver development.
- Drivers can claim MMIO / ports
- Driver resources (e.g. IRQ/Port/MMIO) claims are automatically cleaned up if the driver dies or is killed
- Drivers can also hook into the process lifecycle to clean up or reset hardware
- No legacy to deal with
- Zig code uses a clean coding style (Zen of Zig)
- Favor reading code over writing code.
- No magic numbers.
- No shortened names unless its for ABI compatibility or acronyms
- Inter-Process Communication (IPC)
- Publish and subscribe to Asynchronous Messages
- Talk to services and processes synchronously
Prerequisites
- Zig 0.16.x — the build is pinned to this line (
.zig-version); other minor versions are rejected, because Zig makes breaking changes between releases pre-1.0. A toolchain manager such as zvm orzigupwill pick up.zig-versionautomatically. - QEMU (
qemu-system-x86_64) — to run and test the kernel. On macOS,brew install qemualso bundles the OVMF firmware below. - OVMF UEFI firmware — the
edk2-ovmfpackage (Arch),ovmf(Debian/Ubuntu), oredk2-ovmf(Fedora); on macOS it ships inside the Homebrewqemuformula. Both the build and the test harness probe the known Arch/Debian/Fedora/macOS layouts and use the first that exists, so no configuration is normally needed. Override with-Dovmf-code=/-Dovmf-vars=(build) if yours lives elsewhere. - Python 3 — for the QEMU integration test harness.
Build
zig build
Produces a FHS-shaped zig-out/ that is the danos filesystem and the boot volume:
the UEFI bootloader at zig-out/EFI/BOOT/BOOTX64.efi, the kernel at
zig-out/system/kernel, init at zig-out/system/services/init, drivers under
zig-out/system/drivers/, the test fixtures under zig-out/test/system/services/,
and the initial-ramdisk at zig-out/boot/.
Release media
zig build release-x86-64
Produces zig-out/danos-x86-64.iso, a hybrid ISO that boots flashed raw to a
USB stick (balenaEtcher, dd) or burned to optical media — see
docs/release-iso.md. zig build check-iso-image
validates it without booting.
Run
Boot it in QEMU with OVMF (opens a display window):
zig build run-x86-64
# distro with OVMF elsewhere:
zig build run-x86-64 -Dovmf-code=/path/OVMF_CODE.fd -Dovmf-vars=/path/OVMF_VARS.fd
Test
zig build test # host unit tests (the platform-independent shared code)
python3 test/qemu_test.py # QEMU integration tests: boots the kernel and asserts
# on its serial output (see docs/testing.md)
The integration harness builds and boots the kernel once per test case, checking memory, the frame allocator, paging (incl. NX and the null guard), the heap, interrupts, and exception handling. It exits non-zero on any failure, so it drops straight into CI.
Documentation
Design notes explaining why behind the code live in
docs/ — start with docs/README.md.
For the hardware needed to run DanOS — minimum specs plus a plain-language guide
matching Intel/AMD CPU generations by name — see
docs/system-requirements.md.
Logo
San Serif Text "Dan OS" with a black karate belt around it.