BoringKernel 0.0.18-dev · x86_64 · C

BoringOS

Ein eigenständiges experimentelles Desktop-Betriebssystem von Grund auf — keine Linux-Distribution, kein BSD-Userspace und kein Wrapper um einen fremden Kernel. BoringOS ist ein eigener Kernel, ein eigener nativer Userspace und ein bewusst kleiner Weg hin zu einem eigenen Desktop. boring is not a bug. it's the entire operating system now.

Quellcode auf GitHub Roadmap ansehen Echten Shell-Beweis ansehen

LIVE eigener x86_64-Kernel
LIVE CPL3-Userspace
LIVE VFS + RAMFS
LIVE PID 1 + Shell
JETZT BoringFS-v0-Codec

Aktuelle Referenzplattform: QEMU x86_64 mit Limine. Echte Hardware kommt später, wenn Plattform- und Storage-Schichten langweilig genug geworden sind.

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 · Architektur

Ein kleiner Stack, der wirklich uns gehört.

Das Projekt wächst Schicht für Schicht. Jede neue Fähigkeit muss die bisherigen QEMU-Acceptance-Gates grün halten, statt sie durch eine neue Demo zu ersetzen.

bootLimineUEFI/QEMU-Bootstrap und defensiv validierte Boot-Metadaten.

kernelBoringKernelMemory, Exceptions, Timer, Prozesse und Privilegtrennung.

userspaceRing 3 + ELFStatische ET_EXEC-Programme in unabhängigen Address Spaces.

system apiSYSCALLKleine BoringOS-native ABI mit geprüftem Userspace-Speicher.

filesystemVFS → RAMFSEchter mutierbarer Namespace, Prozess-CWD und Backend-Dispatch.

programmeinit → shellPID 1 startet PID 2 und übergibt an eine native C-Shell.

Eigenständiger Kernel

Kein Linux-, BSD- oder Redox-Kernel darunter. BoringKernel besitzt den x86_64-Ausführungspfad des Projekts selbst.

Freestanding C-Userspace

Native Programme nutzen eine BoringOS-eigene Runtime: keine Host-libc, kein CRT, kein Dynamic Linker und kein PIE.

Privilegtrennung

Userspace läuft in CPL3 mit getrennten Address Spaces, TSS.RSP0 und einer geprüften nativen SYSCALL/SYSRETQ-Grenze.

Echter Filesystem-State

Die Shell verändert den tatsächlichen RAMFS-Namespace über Userspace-Syscalls, Prozess-CWD und den generischen VFS.

Acceptance-driven

Normalboot, Faults, Ring 3, Syscalls, ELF, Runtime, Console, VFS, RAMFS, Init und Shell bleiben als Regressionstest erhalten.

Desktop als Ziel

Der lange Weg führt zu Framebuffer/Input, einem kleinen nativen Display-Protokoll, BoringWM, Terminal-Clients und später echten Anwendungen.

02 · Nativer Userspace

Der Prompt ist echt.

Der Milestone-17-Test grept keine Fake-Liste. Er injiziert Befehle über die serielle Konsole und prüft spätere unabhängige FS_READDIR-Ausgabe aus dem echten RAMFS.

PID 1 startet PID 2.

boring-init läuft als PID 1 in CPL3. Es betritt den LAUNCH-Syscall, der Kernel bereitet einen unabhängigen PID-2-Address-Space vor, vererbt die retained VFS-CWD und verwandelt den aktiven Trusted-Syscall-Return-Frame in den Shell-Handoff.

Keine verschachtelten lebenden PID1/PID2-Syscall-Frames auf dem globalen Trusted Stack.
PID 1 bleibt PROCESS_ALIVE.
PID 2 führt eine separate freestanding boring-shell.elf aus.
Noch keine FD-Tabelle und keine stdin/stdout/stderr-Abstraktion.

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 [leer] boring>

03 · Roadmap

Vom ersten Frame bis zum persistenten nativen Root.

Die öffentliche Roadmap bildet den Repository-Stand ab. „Geplant“ wird nicht als implementiert verkauft. Milestone 18 läuft aktuell und befindet sich noch im Closeout.

17Milestones abgeschlossen

18aktuell · BoringFS-v0-Codec + Validator

25persistentes natives Root als aktuelles Roadmap-Ziel

Stage 1–3 · Kernel-Grundlagen

Speicher, Interrupts, Scheduling, Prozesse und Ring 3.

COMPLETE

01Physical Memory ManagerDONE

02Virtual Memory ControlDONE

03Kernel HeapDONE

04IDT + ExceptionsDONE

05PIC + PITDONE

06Cooperative ContextsDONE

07Timer PreemptionDONE

08Prozesse + Address SpacesDONE

09Ring-3-TransitionDONE

10Native Syscall-GrenzeDONE

Stage 4–6 · Nativer Userspace

Programme laden, mit dem Kernel sprechen, echten Namespace mounten und den Prompt erreichen.

COMPLETE

11ELF-Userspace-LoaderDONE

12Native C-RuntimeDONE

13Userspace Serial ConsoleDONE

14Filesystem-unabhängiger VFSDONE

15Echter mutierbarer RAMFSDONE

16boring-init · PID 1DONE

17boring-shell · PID 2DONE

Stage 7 · BoringFS Host-Tooling

Eine exakte Interpretation des On-Disk-Formats etablieren, bevor der Kernel Storage berührt.

IN PROGRESS

18BoringFS-v0-Codec + Structural ValidatorCURRENT

19mkboringfsPLANNED

20boringfsckPLANNED

Stage 8–9 · Persistenter Storage

Erst wenn das Format-Tooling sitzt, fasst der Kernel echte persistente Filesystem-Blöcke an.

PLANNED

21Generischer Block-Device-LayerPLANNED

22QEMU VirtIO-blockPLANNED

23Read-only BoringFS-MountPLANNED

24BoringFS-MutationPLANNED

25Persistentes natives Root-FilesystemPLANNED

04 · BoringFS v0

Als Nächstes werden die Bytes langweilig.

Milestone 18 stoppt bewusst vor einem Filesystem-Mount. Er definiert und validiert das exakte Byteformat, das spätere Tools und Kernelcode gemeinsam nutzen sollen.

Ein Format. Explizite Bytes.

Der Codec nutzt explizite Little-Endian-Loads/Stores statt gepackter nativer C-Structs. Der Validator arbeitet auf caller-provided Byte-Buffern und prüft Layout, Bitmap-Ownership, Objekte, Extents, Directories, UTF-8-Namen, Referenzen, Zyklen, Leaks, Overlaps und Truncation.

MagicBORINGFS

Format0.1

Block4096 Bytes

Object Record128 Bytes

Directory Record256 Bytes

Dateiname240 UTF-8-Bytes

Extents / Objektmax. 8

Volumemax. 4 GiB (v0)

v0 Volume-Layout

Block 0
Superblock · Magic, Version, Größen, Layout, Feature-Masks

Allocation Bitmap
Metadata- und Data-Ownership auf 4096-Byte-Blockgranularität

Object Table
Feste 128-Byte-Object-Records mit IDs, Parent und Extents

Data Area
Regular-File-Bytes und logische Directory-Streams

Aktueller M18-Scope: Codec + read-only Structural Validator. Noch kein Formatter-CLI, kein fsck-CLI, kein Blocktreiber und kein Kernel-Mount.

05 · Designprinzipien

Kleine Verträge. Echte Beweise.

BoringOS ist experimentell, aber geplante Schichten werden nicht als bereits implementiert dargestellt.

Kein fremder finaler Kernel

BoringOS ist ein eigenständiges OS-Projekt. Linux, BSD oder andere Kernel bilden nicht die endgültige Ausführungsbasis.

C zuerst, Assembly nur wo nötig

BoringOS-eigene Komponenten sind primär C; kleine isolierte x86_64-Assembly-Stücke bleiben Architekturgrenzen vorbehalten.

Den echten Pfad testen

Acceptance bevorzugt beobachtbaren Runtime-State: echte Privilegwechsel, echte User-Memory-Prüfung, echte Namespace-Mutationen und spätere unabhängige Beobachtung.

Kein vorschnelles POSIX-Cosplay

Die aktuelle Shell hat bewusst noch keine numerische FD-Tabelle und keine stdin/stdout/stderr-Abstraktion. Schnittstellen kommen erst, wenn die Architektur sie wirklich braucht.

Format vor Persistenz

BoringFS bekommt erst einen exakten Codec und Korruptionsvalidator, bevor Formatter-Tools, Block-I/O oder ein Kernel-Filesystem-Backend entstehen.

Das Ziel ist ein Desktop

Nach persistentem nativem Storage kann der Weg zu Framebuffer/Input, kompaktem Display-Protokoll, nativem BoringWM und echten grafischen Clients weitergehen.

Source first

Verfolge das Betriebssystem dabei, wie es weniger imaginär wird.

Source, Architektur-Notizen, BoringFS-Formatspezifikation und die maßgebliche Milestone-Roadmap liegen im öffentlichen GitHub-Repository.

GitHub-Repository Komplette Roadmap BoringFS-Spezifikation