Eigenes Betriebssystem entwickeln: Bootloader und BoringKernel

Ein eigenes Betriebssystem beginnt nicht mit einer Taskleiste. Zuerst muss Code zuverlässig die Kontrolle nach dem Bootloader übernehmen, Informationen über den Rechner verstehen und Speicher verwalten. BoringOS zeigt diesen Weg als eigenes experimentelles x86_64-System mit dem selbst entwickelten BoringKernel.

Die BoringOS-Projektseite zeigt den größeren Stand. Hier erklären wir die Grundlagen für Leute, die noch keinen Kernel geschrieben haben. BoringOS ist ein unabhängiges System mit überwiegend C und kleinen Assembly-Teilen; es ist keine Linux-Distribution. Die Beispiele beginnen im Emulator und verändern keinen echten Bootdatenträger.

Firmware, Bootloader und Kernel haben eigene Rollen

Firmware startet den Rechner und wählt einen Bootweg. Ein Bootloader lädt anschließend das Kernelprogramm und übergibt definierte Informationen. BoringOS verwendet dafür Limine. Der Kernel übernimmt danach die eigene Systemarbeit.

Limine ist dabei ein externes Projekt und kein selbst entwickelter Teil von BoringKernel. Eine klare Grenze macht nachvollziehbar, welche Arbeit der Kernel bereits übernimmt und welche Voraussetzungen er noch vom Bootloader erbt.

Warum ein Kernel anders als ein normales C-Programm ist

Ein gewöhnliches Programm startet in einem vorhandenen Betriebssystem. Es kann auf Prozesse, Dateien und Bibliotheken dieses Systems zurückgreifen. Ein früher Kernel muss diese Umgebung erst bereitstellen.

Der Begriff freestanding beschreibt diesen Unterschied beim C-Bau. Ein erfolgreich kompiliertes C-Programm ist noch kein bootfähiger Kernel: Einstieg, Linker-Anordnung, Architektur und Bootprotokoll müssen zusammenpassen. Ein normales printf ist im frühen Einstieg nicht einfach automatisch vorhanden.

Darum ist eine serielle Ausgabe ein hilfreicher erster Beobachtungsweg. Sie kann Meldungen liefern, bevor ein vollständiger Grafikstack oder ein Dateisystem existiert. Ein Emulator macht diese Ausgabe bequem auf dem Host sichtbar.

Den echten BoringKernel-Einstieg lesen

Die aktuelle Datei kernel/core/entry.c enthält die Funktion boring_kernel_entry. Ein kurzer echter Ausschnitt daraus lautet:

serial_init();
serial_write_string("BoringOS booting...\n");
serial_write_string("BoringKernel 0.0.62-dev\n");

Diese Zeilen stehen innerhalb der vorhandenen Einstiegfunktion. Sie sind keine vollständige bootfähige Datei. Danach folgen Abfragen und Prüfungen für mehrere Systembereiche. Die aktuelle Datei ist deutlich weiter entwickelt als ein „Hello World“-Kernel.

Für das Lesen ist die Reihenfolge entscheidend: Erst braucht die Beobachtung eine Ausgabe, danach können Fehler in der Speicherinitialisierung verständlich gemeldet werden. Der Code prüft Ergebnisse und hält bei grundlegenden Fehlern kontrolliert an, statt trotz ungültiger Voraussetzungen weiterzuarbeiten.

Physischer und virtueller Speicher verständlich trennen

Der physische Speichermanager, kurz PMM, verwaltet nutzbare RAM-Bereiche beziehungsweise Frames. Er muss wissen, welche Bereiche verfügbar sind und welche etwa durch Kernel oder Hardware reserviert bleiben.

Der virtuelle Speichermanager, VMM, behandelt Adresszuordnungen über Seitentabellen. Eine Adresse im Programm ist deshalb nicht automatisch dieselbe Adresse im physischen RAM. Der Bootloader liefert unter anderem Speicherkarte und Informationen über vorhandene Zuordnungen.

BoringOS testet solche Grundlagen gezielt: Zuteilungen sollen beispielsweise ausgerichtet sein, nicht mehrfach denselben Frame vergeben und beim Freigeben korrekt verbucht werden. Ein bestandener Einzeltest beweist eine geprüfte Bedingung, nicht schon die Funktionsfähigkeit eines vollständigen Desktops.

Ältere Dokumente im Repository beschreiben frühe Meilensteine. Für die aktuelle Arbeit sind die konkrete Revision, der aktuelle Einstiegscode und die dokumentierten Abnahmestände wichtiger als eine isolierte alte Bootstrap-Beschreibung.

Einen einfachen Haltepunkt als Lernbeispiel verstehen

Das folgende eigene C-Beispiel zeigt nur eine kontrollierte Warteschleife für x86_64-Kernelkontext:

void tutorial_halt(void) {
    for (;;) {
        __asm__ volatile ("cli; hlt");
    }
}

cli deaktiviert maskierbare Interrupts, hlt hält die CPU bis zu einem passenden Ereignis an. Die Schleife kehrt nicht in eine unbekannte Aufrufumgebung zurück. Solche privilegierten Befehle gehören in Kernelkontext; führe dieses Beispiel nicht als normales Linux-Programm aus.

Es fehlen hier absichtlich Bootprotokoll, Linker-Skript, Ausgabe und sämtliche Geräteinitialisierung. Für einen tatsächlichen Start benutzen wir das vollständige Projekt, statt aus dem kurzen Ausschnitt Bootfähigkeit abzuleiten.

Das Projekt im Emulator kennenlernen

Du brauchst unter anderem eine passende x86_64-GCC/binutils-Toolchain, Make, QEMU, xorriso und die vom Projekt beschriebenen Downloadwerkzeuge. Prüfe die aktuelle Build-Dokumentation und arbeite in einem neuen Checkout:

git clone https://github.com/dennishilk/BoringOS.git

Wechsle in den Ordner:

cd BoringOS

Baue den Standardstand:

make

Starte den Standard-Emulatortest:

make run

Der aktuelle Makefile-Aufruf verwendet eine serielle QEMU-Ausgabe ohne Grafikfenster. Das ist ein Bootstrap-/Testweg und nicht automatisch die vollständige grafische BoringWM-Demo. Der sichtbare Zustand hängt auch vom gewählten Testmodus ab. Beende diesen im Vordergrund laufenden QEMU-Test mit Strg + C; die verwendete stdio-Anbindung erlaubt standardmäßig dieses Terminalsignal.

Vom Kernel zum eigenen Desktop

Für den Desktop kommen unter anderem Scheduler, Ring-3-Prozesse, native Systemaufrufe, VFS und BoringFS sowie Display- und Eingabedienste hinzu. Erst darauf können BoringWM, Terminal, Editor und Dateiverwaltung sinnvoll arbeiten.

Der Projektstand dokumentiert reale Tests auf Cthulhu, unter anderem USB/HID und einen 1920×1080-Desktop. Solche Aussagen gehören zu konkreten Abnahmerevisionen. Eine spätere Optimierung mit bestandenen automatischen Tests ist nicht automatisch derselbe physisch geprüfte Stand.

QEMU hilft beim reproduzierbaren Entwickeln, ersetzt aber keine Prüfung jeder USB-Topologie oder echten Grafikhardware. Für Einsteiger ist der Emulator trotzdem der passende erste Ort: Beobachte den Boot, lies eine Funktion und verfolge eine einzelne geprüfte Voraussetzung.

Quellen und nächste Schritte

• BoringOS auf GitHub.
• Geprüfter Kernel-Einstieg und Makefile.
• Aktueller Projektstand und physische Referenzen.
• Limine-Bootprotokoll und QEMU-Dokumentation.

Quellenstand: 8. Oktober 2026. Wer besonders die Anzeige spannend findet, findet im Framebuffer-Artikel ein kleines Beispiel für Pixeladressierung.