BoringKernel 0.0.18-dev · x86_64 · C

BoringOS

An independent experimental desktop operating system built from scratch — not a Linux distribution, not a BSD userland and not a wrapper around another kernel. BoringOS is its own kernel, its own native userspace and a deliberately small path toward a native desktop. boring is not a bug. it's the entire operating system now.

View source on GitHub Explore the roadmap See the real shell proof

LIVE own x86_64 kernel
LIVE CPL3 userspace
LIVE VFS + RAMFS
LIVE PID 1 + shell
NOW BoringFS v0 codec

Current reference platform: QEMU x86_64 with Limine. Real hardware comes later, after the platform and storage layers are boring enough.

serial0 · BoringOS boot

[boot] BoringOS booting... BoringKernel 0.0.18-dev [arch] x86_64 boring-init: starting boring-init: pid 1 boring-init: online boring-init: launching boring-shell boring-shell: starting boring-shell: pid 2 boring-shell ready. boring> mkdir Test boring> ls Test boring> cd Test boring> mkdir Inner boring> ls Inner boring>

01 · Architecture

A small stack that is actually ours.

The project advances layer by layer. Each new capability keeps the previous QEMU acceptance gates green instead of replacing them with a new demo.

bootLimineUEFI/QEMU bootstrap and validated boot metadata.

kernelBoringKernelMemory, exceptions, timer, processes and privilege separation.

userspaceRing 3 + ELFStatic ET_EXEC programs in independent address spaces.

system APISYSCALLSmall BoringOS-native ABI with checked user memory.

filesystemVFS → RAMFSReal mutable namespace, process CWD and backend dispatch.

programsinit → shellPID 1 launches PID 2 and hands control to a native C shell.

Independent kernel

No Linux, BSD or Redox kernel underneath. BoringKernel owns the x86_64 execution path used by the project.

Freestanding C userspace

Native programs use a BoringOS-owned runtime: no host libc, no CRT, no dynamic linker and no PIE.

Privilege separation

Userspace executes at CPL3 with separate address spaces, TSS.RSP0 and a checked native SYSCALL/SYSRETQ boundary.

Real filesystem state

The shell mutates the actual RAMFS namespace through userspace syscalls, process CWD and the generic VFS.

Acceptance driven

Normal boot, faults, Ring 3, syscalls, ELF, runtime, console, VFS, RAMFS, init and shell remain regression-tested.

Desktop is the destination

The long path leads toward framebuffer/input, a small native display protocol, BoringWM, terminal clients and eventually real applications.

02 · Native userspace

The prompt is real.

The milestone-17 shell test does not grep a fake listing. It injects commands over the serial console and checks later independent FS_READDIR output from the real RAMFS.

PID 1 launches PID 2.

boring-init runs as PID 1 at CPL3. It enters the LAUNCH syscall, the kernel prepares an independent PID 2 address space, inherits the retained VFS CWD and transforms the active trusted syscall return frame into the shell handoff.

No nested live PID1/PID2 syscall frames on the global trusted stack.
PID 1 remains PROCESS_ALIVE.
PID 2 executes a separate freestanding boring-shell.elf.
No FD table and no stdin/stdout/stderr abstraction yet.

boring> mkdir Test boring> ls Test boring> mkdir Test mkdir: already exists boring> cd Test boring> mkdir Inner boring> ls Inner boring> cd .. boring> rmdir Test rmdir: directory not empty boring> cd Test boring> rmdir Inner boring> cd .. boring> rmdir Test boring> ls [empty] boring>

03 · Roadmap

From first frame to persistent native root.

The public roadmap reflects repository state. “Planned” is not presented as implemented. Milestone 18 is currently in progress and still in closeout.

17milestones complete

18current milestone · BoringFS v0 codec + validator

25persistent native-root target in the current roadmap

Stage 1–3 · Kernel foundations

Memory, interrupts, scheduling, processes and Ring 3.

COMPLETE

01Physical memory managerDONE

02Virtual memory controlDONE

03Kernel heapDONE

04IDT + exceptionsDONE

05PIC + PITDONE

06Cooperative contextsDONE

07Timer preemptionDONE

08Processes + address spacesDONE

09Ring 3 transitionDONE

10Native syscall boundaryDONE

Stage 4–6 · Native userspace

Load programs, talk to the kernel, mount a real namespace and reach the prompt.

COMPLETE

11ELF userspace loaderDONE

12Native C runtimeDONE

13Userspace serial consoleDONE

14Filesystem-independent VFSDONE

15Real mutable RAMFSDONE

16boring-init · PID 1DONE

17boring-shell · PID 2DONE

Stage 7 · BoringFS host tooling

Establish one exact interpretation of the on-disk format before kernel storage.

IN PROGRESS

18BoringFS v0 codec + structural validatorCURRENT

19mkboringfsPLANNED

20boringfsckPLANNED

Stage 8–9 · Persistent storage

Only after the format tooling is solid does the kernel touch real persistent filesystem blocks.

PLANNED

21Generic block-device layerPLANNED

22QEMU VirtIO-blockPLANNED

23Read-only BoringFS mountPLANNED

24BoringFS mutationPLANNED

25Persistent native root filesystemPLANNED

04 · BoringFS v0

The bytes get boring next.

Milestone 18 deliberately stops before mounting a filesystem. It defines and validates the exact byte format that later tooling and kernel code will share.

One format. Explicit bytes.

The codec uses explicit little-endian loads/stores rather than packed native C structs. The validator works on caller-provided byte buffers and checks layout, bitmap ownership, objects, extents, directories, UTF-8 names, references, cycles, leaks, overlaps and truncation.

MagicBORINGFS

Format0.1

Block4096 bytes

Object record128 bytes

Directory record256 bytes

Filename240 UTF-8 bytes

Extents / object8 max

Volume4 GiB max (v0)

v0 volume layout

Block 0
Superblock · magic, version, sizes, layout, feature masks

Allocation bitmap
Metadata + data ownership at 4096-byte block granularity

Object table
Fixed 128-byte object records with IDs, parent and extents

Data area
Regular-file bytes and logical directory streams

Current M18 scope: codec + read-only structural validator only. No formatter CLI, no fsck CLI, no block driver and no kernel mount yet.

05 · Design principles

Small contracts. Real proofs.

BoringOS is experimental, but the project avoids pretending that planned layers already exist.

No borrowed final kernel

BoringOS is an independent OS project. Linux, BSD and other kernels are not the final execution foundation.

C first, assembly only where required

BoringOS-owned components are primarily C, with small isolated x86_64 assembly at architecture boundaries.

Test the real path

Acceptance prefers observable runtime state: real privilege transitions, real user memory validation, real namespace mutations and independent later observations.

No premature POSIX cosplay

The current shell deliberately has no numeric file-descriptor table or stdin/stdout/stderr abstraction. Interfaces are added when the architecture actually needs them.

Format before persistence

BoringFS gets an exact codec and corruption validator before formatter tools, block I/O or a kernel filesystem backend.

The destination is a desktop

After persistent native storage, later work can move toward framebuffer/input, a compact display protocol, native BoringWM and real graphical clients.

Source first

Follow the operating system as it becomes less imaginary.

Source, architecture notes, BoringFS format documentation and the authoritative milestone roadmap live in the public GitHub repository.

GitHub repository Full roadmap BoringFS spec