everos8

The everos/8 project is a minimal operating system for x86, written in C and assembly. Everything in the system is a node in a hierarchical namespace tree, inspired by Plan 9 from Bell Labs.

The design

In Plan 9, there is no distinction between reading a file, querying a process, or talking to a device, every resource is a path you open, read, and write. everos/8 applies the same idea at the smallest possible scale:

/
├── dev/
│ ├── cons read: keyboard | write: screen
│ ├── null discards writes, returns empty on read
│ └── rand returns pseudo-random bytes on read
├── proc/
│ └── shell read: current process state
├── sys/
│ ├── version
│ └── motd
└── fs/ user-created files

ns_read(node, buf, len) works identically whether node is a plain file, a device, or a proc entry. That uniformity is the entire point.

Memory layout

0x010000 – 0x1FFFFF kernel image (code + data + stack)
0x200000 – 0x3FFFFF kernel heap (kmalloc free-list allocator)
0x400000 – userland / musl brk region

The heap is a first-fit free-list allocator with immediate coalescing on kfree. kmalloc / kzalloc / kfree are available everywhere in the kernel after mm_init().

Syscall ABI

Userland communicates with the kernel via int 0ドルx30 (not Linux's int 0ドルx80). The register convention mirrors i386 Linux so musl can be ported with a one-file change:

Syscalls implemented so far:

musl libc port

everos/8 ships with a port of musl libc 1.2.4 under musl/. The entire port required changing exactly two files from upstream:

All 1500+ other musl source files are unmodified. Apps in apps/ are compiled against musl and linked statically into the kernel binary, so standard headers like <unistd.h>, <string.h>, and <stdlib.h> work out of the box.

musl port status:

Writing an app

Apps live in apps/ and are compiled with musl headers. Add an entry to the table in src/kernel/app.c to register it with the shell.

// apps/hello.c
#include <unistd.h>
int hello_main(void) {
 const char msg[] = "hello from everos/8\n";
 write(1, msg, sizeof(msg) - 1);
 return 0;
}

// src/kernel/app.c — register the new app
static const App apps[] = {
 { "hello", hello_main },
 { "myapp", myapp_main }, // add here
};

From the shell:

/ apps — list available apps
/ run hello — run an app

Requirements

sudo apt install binutils gcc-multilib qemu-system-x86 make gdb

Tested on Debian 13 (trixie) x86-64. The toolchain targets i386.

Building

make

Produces everos.img, a raw ~1.40 MB disk image.

Running

make run # inside the terminal (QEMU curses display)
make run-sdl # separate SDL window

To quit QEMU: Ctrl-A then X (curses), or close the window (SDL).

Manual invocation:

qemu-system-i386 -drive file=everos.img,format=raw,index=0,media=disk -m 32M

Debugging

make debug

Starts QEMU paused and waiting for GDB on port 1234, then launches GDB connected to it.

Shell commands

Tab completion and arrow-key history navigation are supported.

Boot sequence

1. QEMU loads the boot sector (boot.S) at 0x7C00 in real mode.
2. The bootloader reads 32 sectors from disk into physical address 0x10000 via INT 13h.
3. A20 is enabled, the GDT is loaded, and the CPU switches to 32-bit protected mode.
4. Execution jumps to entry.S at 0x10000, which sets up segment registers and the stack.
5. kernel_main() initialises the heap, VGA, namespace tree, process table, and IDT.
6. The scheduler loop runs shell_run() on every tick.

Limitations

• No virtual memory or paging.
• No hardware timer; the scheduler is purely cooperative.
• Apps are linked statically into the kernel image (no on-disk loading yet).
• No disk persistence — the namespace resets on reboot.
• x86 (i386) only.