Building SlOS

SlOS is a small operating system written in C and architecture-specific assembly. Its native x86-64 and AArch64 kernels run private ELF64 applications, with a freestanding SDK for C and a local Hew runtime.

Use the first-run guide to boot a VM, or the application workbench to edit, build and run your own project. The kernel source is currently private; local build commands assume an existing checkout.

A platform for inspectable applications

The distributed renderer calculates across native x86-64 and AArch64 guests. The durable debugger follows accepted work through assignment, process and configuration records, retaining visibly historical evidence when a source is offline.

The developer workbench adds guest editing, compiler diagnostics, last-good program selection and saved-project recovery. Its ledger and actor-queue examples keep application data separate from code versions.

Kernel architectures and user programs

Both native targets provide an LP64 SDK and load static ELF64 programs into private user address spaces: CPL3 on x86-64 and EL0 on AArch64. Full-width syscalls use INT 0x80 or SVC. x86-32 is retired; old executables are not a compatibility ABI.

Variant	Artifact	Current scope
x86-64	`build/x86_64/slos-x86_64.bin`; `slos-x86_64.iso`	GRUB ISO boot, VirtIO devices, private native user programs and host-compiled Hew.
AArch64 QEMU virt	`build/aarch64-qemu_virt/slos-aarch64.img`	ARM64 Image boot with the firmware device tree, VirtIO MMIO and native user programs. The `.bin` retains ELF symbols.
AArch64 physical boards	`BOARD=rpi5` / `BOARD=h700`	Board variants build. Physical boot, storage and NIC operation are not established by QEMU results; these targets remain UP.

Physical-board builds do not establish physical boot, storage or networking. The working examples on this site use QEMU. Older i386 desktop and DOOM recordings remain historical demonstrations.

Build tools and first boot

Use Linux, GNU Make and Python 3. x86-64 needs native GCC/binutils, NASM, GRUB, xorriso and QEMU; AArch64 needs matching native or cross GCC/binutils and QEMU. Native builds do not require GCC multilib. DOOM and the Hew compiler are optional, not prerequisites for ordinary OS development.

make doctor
make first-user-check
make dev

Select an architecture, board or SDK build

make DOOM=0
make ARCH=x86_64 DOOM=0
make ARCH=aarch64 BOARD=qemu_virt DOOM=0
make ARCH=aarch64 BOARD=rpi5 DOOM=0
make sdk DOOM=0
make ARCH=aarch64 sdk DOOM=0
# Single-core debugging of a native QEMU target:
make dev SMP=0 CPUS=1

make selects AArch64 on an ARM64 host and x86-64 otherwise. Objects and ISO staging are separate for each architecture and board. Compiler and feature-option changes invalidate cached configuration.

make dev opens a disposable native serial VM without host forwarded ports. An explicit DEV_DISK requests persistence. Save work under /home, shut down with halt, and keep backups before changing persistent images.

Scheduling and the language boundary

x86-64 and AArch64/QEMU virt default to SMP=1 CPUS=4. Explicitly AP-pinned, service-free kernel work is timer-preempted. User processes, allocation, filesystems, networking, and general services remain on CPU 0. Native automatic offload, migration, and inter-core actor transport are not implemented. SMP=0 CPUS=1 retains UP debugging.

Kernel actors provide named mailboxes and typed messages; mesh and federation extend delivery and causal replication between nodes. The local Hew runtime has its own cooperative actors and tasks inside one user process. A Hew actor is not a kernel thread or automatic multicore work.

The host compiles Hew with matching library and runtime inputs, then links it against the generic SlOS SDK. Neither Hew nor LLVM runs inside the guest. The local freestanding runtime implements a supported subset, not the full upstream runtime or standard library.

What to expect from the current platform

Native guests exercise private user execution, the SDK, persistent files, shell pipelines and host-compiled Hew. The workbench's build, diagnostic, rollback and recovery paths run on both x86-64 and AArch64/QEMU virt. The persistent queue also has a bounded full-day workload on each target.

These examples establish their exercised operations, not all programs or devices. A successful kernel build alone does not establish user execution, multicore behaviour or physical hardware support. make check DOOM=0 exercises the selected native core; focused application and subsystem checks remain separate.

SlFS v2 supports explicit redo recovery. Saved-project recovery preserves an interrupted original, verifies a new copy, and imports only checked project files into a fresh session. Application data outside that project and unsaved buffers require their own backups.

The causal ring, journal and storage pools are bounded. Replay analyses recorded events rather than restoring arbitrary machine or device state. Mesh cryptography, remote shells and trusted-LAN application services are research implementations, not audited deployment infrastructure.

Explore the application guide, compute recordings, debugger and dated kernel visual atlas. The older i386 showcase remains available with its original scope.