Daniel Samson
77d2e22ed1
The system now boots off a real FAT32 filesystem on a USB mass-storage device instead of QEMU's synthesized VVFAT drive. A new in-repo image builder formats that filesystem from the FHS boot tree, and both QEMU call sites (the run step and the test harness) attach it as a usb-storage device on the xHCI bus, so every boot exercises the full USB path OVMF -> BOOTX64.efi -> kernel. - tools/make-fat-image.py: a Python 3 stdlib-only FAT32 formatter (mirrors tools/make-initial-ramdisk.py — no external host dependencies). It lays down the boot sector + BPB/EBPB32, FSInfo, backup boot sector, two FATs, and the root/subdir/file cluster chains, emitting long-name entries where a name is not 8.3. Packs the four boot inputs (EFI/BOOT/BOOTX64.efi, system/kernel, system/services/init, boot/initial-ramdisk.img) into their boot paths. A --verify subcommand re-checks the 0xAA55 signature, recomputes the cluster count -> FAT32, and resolves EFI/BOOT/BOOTX64.efi, all with no dependencies. - build.zig: a mk_fat step builds zig-out/danos-usb.img from the four boot artifacts (so changing -Dtest-case rebuilds the image with that kernel), a check-fat-image step runs --verify, and run-x86-64 boots the image on a usb-storage device (if=none,id=bootusb + usb-storage,bus=xhci.0,bootindex=0), keeping usb-kbd/usb-mouse on the same controller. - test/qemu_test.py: the default boot config now boots off danos-usb.img on a usb-storage device (xHCI + usb-kbd + usb-mouse + the boot stick). The seven per-case qemu_extra blocks that added their own qemu-xhci/usb-kbd/usb-mouse (or a VVFAT stick) collided on id=xhci and are removed — the default provides the bus and the boot device. usb-storage and fat-mount now exercise the real FAT32 boot image (usb-storage reads its 0x55AA boot sector; fat mounts it at /mnt/usb). A build_case override lets a case reuse another's kernel, used by a new usb-boot case: an explicit, named boot-from-USB regression guard. Verified: zig build, zig build test, and zig build check-fat-image are green (FAT32, 128992 clusters, BOOTX64.efi present); a broad sequential QEMU sweep passes — smoke, init, vfs, input, device-manager, usb-report, usb-hid, usb-storage, fat-mount, device-list, driver-restart, acpi-report, iommu, orderly-shutdown, usb-boot, dma, msi, initial-ramdisk, args, process — proving the boot switch holds across kernel tests, the full init tree, the USB stack, the FAT mount, and orderly shutdown.
DanOS
Codename: Shodan Version: 1
A small resilient operating system, written from scratch in Zig.
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 lifecyle 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 shortend 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/, and the initial-ramdisk at zig-out/boot/.
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.