ONCRIX
Home / Roadmap

Roadmap & status

An early-stage but actively developed microkernel that already boots to a POSIX-style userland.

Status today

ONCRIX is early-stage and under active development. It is not a finished operating system, and nothing here should be read as production-ready. What it is: a real, from-scratch microkernel that compiles for bare-metal x86_64, boots in QEMU under a CI-gated integration test, and hands control to a small user-space init that launches a shell and a handful of embedded coreutils. The kernel keeps only scheduling, memory management, and IPC; drivers, filesystems, and services live in user space and talk over message passing. The surface area grows steadily — POSIX system calls, virtual filesystem behaviour, and the beginnings of capability-based access control are all being filled in iteratively.

The honest summary: the foundations boot and run, but most subsystems are still partial. Treat the lists below as a snapshot of direction and progress, not a feature checklist of a complete OS.

Reading the labels. Throughout this page, working means it builds and runs today in CI; in progress means it exists but is incomplete or being actively reshaped; and planned means it is on the roadmap but not yet started in earnest.

What works

Boots, runs, and grows

These pieces exist today and are exercised on every change — the kernel builds for x86_64-unknown-none and boots all the way to a user-space shell in the CI boot test.

CapabilityWhat it coversStatus
Bare-metal build Compiles for x86_64-unknown-none as a #![no_std] #![no_main] kernel. working
Boot to userland Boots in QEMU, validated by a CI-gated boot integration test that confirms the kernel reaches user space. working
POSIX system calls A growing set: file I/O (read, write, open, close, lseek), process control (fork, execve, exit, wait), memory (mmap), plus pipes, signals, and more. working
Virtual filesystem A VFS layer with an in-memory ramfs backing the early userland. working
User-space init An init process that launches a shell and a set of embedded coreutils in user space. working
IPC primitives Channels, shared memory, and message queues — the spine that connects user-space services. working
Capability foundations The start of capability-based access control — a foundation being built, not a finished model. in progress

Concretely, a typical session today looks like booting the kernel image under QEMU, watching init come up, and dropping into the shell to run the embedded coreutils against the in-memory filesystem — the same path the CI boot test walks automatically.

boot image → kernel (scheduler / mm / IPC) → init (user space) → shell + embedded coreutils → syscalls → VFS + ramfs

In progress

Being filled in right now

These areas exist in some form but are incomplete, evolving, or actively being reshaped. Expect rough edges and breaking changes.

  • in progress  Capability-based access control. The groundwork is in place; the access-control model, capability handles, and privilege separation between user-space services are still being designed and extended.
  • in progress  POSIX coverage. New system calls land continuously, with each one validated against the POSIX.1-2024 interface contract before it is considered usable.
  • in progress  VFS depth. Beyond the in-memory ramfs, the VFS layer is being generalised so additional filesystem backends can plug in cleanly.
  • in progress  User-space services. Moving more functionality out of the kernel and behind IPC, in line with the microkernel goal of a minimal trusted computing base.

Planned

On the roadmap

Directions ONCRIX intends to take. These are not started in earnest yet — they describe where the project is heading, not what it does today.

  • planned  More filesystems. Additional VFS backends such as ext2, fat32, and tmpfs, running as user-space services on top of the existing VFS layer.
  • planned  Maturing network stack. Growing networking support so user-space applications can communicate over the network.
  • planned  More user-space drivers. Broadening the set of devices handled by isolated, message-passing drivers in user space.
  • planned  SMP / multi-core. Scheduling and synchronisation across multiple cores.
  • planned  Demand paging and copy-on-write. Richer memory management in the mm crate for lazy mapping and efficient fork.
  • planned  aarch64 / riscv64 bring-up. Extending beyond the primary x86_64 target to the secondary aarch64 and tertiary riscv64 targets, with architecture-specific code kept behind the HAL.

The trajectory

From a booting kernel outward

A rough ordering of how the project is layering up — each stage builds on the one before it.

  • Foundations working

    Bare-metal x86_64 build, QEMU boot to user space, a CI boot integration test, IPC primitives, a VFS with in-memory ramfs, and an init that launches a shell with embedded coreutils.

  • POSIX surface in progress

    An expanding set of POSIX.1-2024-compatible system calls — file I/O, process control, memory, pipes, and signals — landing one validated call at a time.

  • Capability model in progress

    Building out capability-based access control and privilege separation between user-space services on top of the existing foundation.

  • Storage & networking planned

    More filesystem backends (ext2, fat32, tmpfs), a maturing network stack, and more user-space device drivers behind IPC.

  • Scale & portability planned

    SMP / multi-core scheduling, demand paging and copy-on-write in the memory manager, and aarch64 / riscv64 bring-up behind the HAL.

No dates, no benchmarks. ONCRIX is a from-scratch research and engineering effort with no committed timelines. The ordering above reflects intent and dependency, not a schedule — the most accurate, up-to-date picture always lives in the repository and its commit history.

Follow the progress

The source, the design docs, and the full commit history are public — that is where the roadmap actually moves.

github.com/kernalix7/oncrix See how it fits together