jsix

Das JSIX -Betriebssystem

JSIX ist ein benutzerdefiniertes Multi-Core-X64-Betriebssystem, das ich von Grund auf neu baue. Es ist alles andere als fertig oder sogar nutzbar (siehe den Status und den Roadmap- Abschnitt unten), aber alle derzeit geplanten großen Kernelfunktionen werden nun mindestens ein passables Niveau implementiert.

Die Designziele des Projekts sind:

• Moderne - Ich bin nicht daran interessiert, für Legacy -Systeme zu entwerfen oder auf der gesamten Hardware zu laufen. Mein Ziel ist nur 64 -Bit -Architekturen und moderne Warenhardware. Derzeit bedeutet dies X64 -Systeme mit Nehalem oder neuerem CPUs und UEFI -Firmware. (Sehen Sie sich diese Liste für die derzeit erforderlichen CPU-Funktionen an.) Schließlich möchte ich an einem AARG64-Port arbeiten, um mich teilweise zu zwingen, die architekturabhängigen Teile der Codebasis zu berücksichtigen.

• Modularität - Ich möchte so viel von dem System in mikrokernel -Art und Weise in getrennte Prozesse herausziehen. Ein Untertor davon besteht darin, zu untersuchen, wo die Engpässe eines solchen Mikrokernels jetzt sind und ob ich ein System entwerfen kann, das von den traditionellen Microkernel-Problemen weniger festgefahren ist.

• Erkundung - Ich mache dies wirklich meistens, um Spaß daran zu haben, die moderne OS -Entwicklung zu lernen und zu erforschen. Erste Feature -Implementierungen können das modulare Design vorübergehend wegwerfen, um die zugehörige Hardware zu ermöglichen.

Ein Hinweis zum Namen: Dieser Kernel wurde ursprünglich Popcorn genannt, aber ich habe seitdem festgestellt, dass das Popcorn Linux -Projekt auch einen Kernel mit diesem Namen entwickelt und ungefähr zur gleichen Zeit wie dieses Projekt begann. Also habe ich diesen Kernel JSIX (immer als JSIX oder j6 , nie aktiviert) als Hommage an L4, XV6 und meine wundervolle Frau umbenannt.

Status und Roadmap

Die folgenden Hauptmerkmale sind Ziele für die JSIX -Entwicklung:

UEFI -Bootloader

Erledigt. Der Bootloader lädt die Kernel- und Erst -UserSpace -Programme und legt die erforderlichen Kernel -Argumente zur Speicherkarte und zum EFI -GOP -Framebuffer ein. Mögliche zukünftige Ideen:

• Übernehmen Sie mehr Init-Zeit-Funktionen vom Kernel
• Schreiben Sie es in Zig um

Erinnerung

Virtueller Speicher: ausreichend. Der Kernel verwaltet das virtuelle Speicher mit einer Reihe von Arten von vm_area -Objekten, die kartierte Bereiche darstellen, die zu einem oder mehreren vm_space -Objekten gehören können, die einen ganzen virtuellen Speicherplatz darstellen. (Jeder Prozess hat einen vm_space , ebenso wie der Kernel selbst.)

Verbleibend zu tun:

• TLB -Shootdowns
• Seitenwipping
• Große / riesige Seitenunterstützung

Physikalische Seitenzuweisung: ausreichend. Die aktuelle Implementierung für physikalische Seite Allocator verwendet eine Gruppe von Blöcken, die UP-1GIB-Bereiche mit nutzbarem Speicher darstellen, wie vom Bootloader definiert. Jeder Block verfügt über eine dreistufige Bitmap, die kostenlose/gebrauchte Seiten bezeichnet.

Zukünftige Arbeit:

• Richten Sie Blöcke so aus, dass ihre erste Seite 1Gib ausgerichtet ist, was die Suche nach freien großen/riesigen Seiten erleichtert.

Multitasking

Ausreichend. Das globale Scheduler -Objekt hält separate bereit/blockierte Listen pro Kern. Kerne versuchen regelmäßig, die Belastung durch Arbeiten zu gleichen.

Benutzer-Raum-Aufgaben können sowohl Threads als auch andere Prozesse erstellen.

API

SYSCALLS: Ausreichend. Benutzer-Raum-Aufgaben können sympathisch zum Kernel über schnelle Anweisungen für Syscall/Sysret machen. SYSCalls, die über libj6 hergestellt wurden, schauen Sie sowohl auf den Callee als auch den Anrufer wie Standard -SYSV ABI -Funktionsaufrufe. Die Implementierungen sind in generierte Wrapper -Funktionen eingewickelt, die die Anforderung, die Überprüfung von Funktionen und die entsprechenden Kernelobjekte oder -handles finden, bevor die Implementierungsfunktionen aufgerufen werden.

IPC: Arbeiten, muss optimiert werden. Die aktuellen IPC -Primitiven sind:

• Postfächer : Endpunkte für asynchron gelieferte kleine Nachrichten. Derzeit werden diese Nachrichten doppelt hergestellt - einmal vom Anrufer in einen Kernelpuffer und einmal vom Kernel zum Empfänger. Dies funktioniert und ist keine Hauptursache für eine Verlangsamung, muss aber in Zukunft optimiert werden.
• Kanäle : Endpunkte für asynchrone uni-direkte Ströme von Bytes. Derzeit leiden diese auch unter einem Problem mit doppelter Kopie und sollten wahrscheinlich schließlich durch die gemeinsam genutzte Speicherkommunikation von UserSpace ersetzt werden.
• Ereignisse : Objekte, die signalisiert werden können, um asynchrone Benachrichtigungen an Wartefäden zu senden.

Hardwareunterstützung

• Framebuffer -Treiber: in Arbeit. Derzeit startet JSIX auf Maschinen mit einem von UEFI zugänglichen Videogerät einen Benutzer-Raum-Framebuffer-Treiber, der nur Kernel-Protokolle ausdruckt.
• Serienfahrer: in Arbeit. Der aktuelle UART setzt COM1 derzeit nur als Ausgangskanal aus, aber keine Eingabe oder andere serielle Anschlüsse werden freigelegt.
• USB -Fahrer: Um zu tun
• Ahci (Sata) Fahrer: zu tun

Gebäude

JSIX verwendet das Ninja Build -Tool und generiert die Build -Dateien mit dem configure . Der Build basiert auch auf eine benutzerdefinierte Toolchain-Sysroot, die mit den Skripten in JSIX-OS/Toolchain heruntergeladen oder erstellt werden kann.

Andere Bauabhängigkeiten:

• Klang: Der C/C ++ - Compiler
• Nasm: Der Assembler
• LLD: Der Linker
• Mtools: zum Erstellen des fetten Bildes

Das configure verfügt über einige Python -Abhängigkeiten - diese können über pip installiert werden, obwohl dies in einer virtuellen Python -Umgebung empfohlen wird. Die Installation über pip installiert auch ninja .

Ein Debian 11 (Bullseye) -System kann mit den erforderlichen Build -Abhängigkeiten konfiguriert werden, indem die folgenden Befehle aus dem JSIX -Repository -Root ausgeführt werden:

sudo apt install clang lld nasm mtools python3-pip python3-venv
python3 -m venv ./venv
source venv/bin/activate
pip install -r requirements.txt
peru sync

Einrichten des Systems

Erstellen oder laden Sie den Toolchain SySroot wie oben erwähnt mit JSIX-OS/Toolchain und symlink das erstellte Toolchain-Verzeichnis als sysroot am Wurzel dieses Projekts.

 # Example if both the toolchain and this project are cloned under ~/src
ln -s ~ /src/toolchain/toolchains/llvm-13 ~ /src/jsix/sysroot

Bauen und Laufen JSIX

Sobald die Toolchain eingerichtet wurde, setzt das Ausführen des Skripts ./configure (siehe ./configure --help für verfügbare Optionen) die Build -Konfiguration ein, und ninja -C build (oder wo immer Sie das Build -Verzeichnis einstellen) wird der Build tatsächlich ausgeführt. Wenn Sie qemu-system-x86_64 installiert haben, wird das qemu.sh Skript JSIX im QEMU -nographic Modus ausführen.

Ich persönlich führe dies entweder von einer echten Debian AMD64 Bullseye -Maschine oder einer Windows WSL -Debian Bullseye -Installation aus. Ihre Kilometerleistung kann mit anderen Setups und Distributionen variieren.

Ausführen der Testsuite

JSIX verfügt nun über das test_runner UserSpace -Programm, in dem verschiedene automatisierte Tests ausgeführt werden. qemu.sh ist nicht im Standard -Build enthalten. Wenn Sie das test.yml test.sh .

./configure --manifest=assets/manifests/test.yml
if ./test.sh ; then echo " All tests passed! " ; else echo " Failed. " ; fi