T

Daniel Samson 8a38540312 Phase 2d (i): a kernel wall-clock from the CMOS RTC

Adds real (calendar) time, the foundation for filesystem timestamps. Monotonic
time (`clock`) says how long since boot; this says what time it actually is.

- cpu.zig (x86_64): readRtcUnixSeconds() reads the CMOS real-time clock (ports
  0x70/0x71) — waits out an update-in-progress, reads twice until stable, handles
  BCD-vs-binary and 12-vs-24-hour per status register B — and converts to Unix
  epoch seconds (UTC).
- kernel/wall-clock.zig: reads the RTC once at boot and anchors it to the monotonic
  clock, so a query is a cheap arithmetic offset — no per-call CMOS poll, no lock,
  no SMP hazard on the shared ports. kmain calls init() once the monotonic clock is
  final and logs the epoch.
- wall_clock() syscall (33) -> Unix epoch seconds, wrapped by runtime.system
  .wallClock(). Wall-clock *seconds* are mechanism the kernel owns like the
  monotonic clock; calendars/timezones are user-space policy (the stale comment on
  systemClock that called wall-clock a "user-space service" is updated in spirit by
  the new handler's doc).
- A `wall-clock` kernel test asserts the boot RTC read is a plausible current epoch.

Verified against the host: the guest read epoch 1783971244 while `date -u +%s` gave
1783971245 (one second of boot lag) — the CMOS read + epoch conversion are correct to
the second. zig build, zig build test, and smoke/clock/init are green.

2026-07-13 20:35:03 +01:00

boot

fix efi: debug prefix

2026-07-13 05:30:56 +01:00

docs

Phase 2c: rename, wired through the VFS to runtime.fs

2026-07-13 20:22:32 +01:00

library

Phase 2d (i): a kernel wall-clock from the CMOS RTC

2026-07-13 20:35:03 +01:00

system

Phase 2d (i): a kernel wall-clock from the CMOS RTC

2026-07-13 20:35:03 +01:00

test

Phase 2d (i): a kernel wall-clock from the CMOS RTC

2026-07-13 20:35:03 +01:00

tools

M7: in-repo FAT32 image builder + boot the whole system off a USB stick

2026-07-13 15:34:18 +01:00

.editorconfig

editorconfig

2026-07-12 16:09:11 +01:00

.gitattributes

gitattributes

2026-07-12 16:09:18 +01:00

.gitignore

gitignore: ignore .claude/ and .github/

2026-07-10 14:09:38 +01:00

.zig-version

Pin zig version to 0.16 LTS

2026-07-03 13:49:47 +01:00

build.zig

Phase 1a: add the native runtime.fs, retire the posix shim

2026-07-13 19:43:56 +01:00

build.zig.zon

started project with basic efi setup

2026-07-01 18:32:56 +01:00

README.md

Docs: link README to system-requirements.md

2026-07-13 11:10:24 +01:00

README.md

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 or zigup will pick up .zig-version automatically.
QEMU (qemu-system-x86_64) — to run and test the kernel. On macOS, brew install qemu also bundles the OVMF firmware below.
OVMF UEFI firmware — the edk2-ovmf package (Arch), ovmf (Debian/Ubuntu), or edk2-ovmf (Fedora); on macOS it ships inside the Homebrew qemu formula. 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.