ChaOS
Überblick
ChaOS ist mein kleines Betriebssystem, welches ich für mein Studium entwickle. Es soll mir dabei helfen, die Konzepte eines Betriebssystem durch Praxis zu verinnerlichen. Ich werde mich darauf konzentrieren, die rudimentären Dinge einzubauen, damit es realitätsnah an echten modernen Betriebssystemen ist.
Architektur und Designentscheidungen
Warum ARM?
Ich habe mich für ARM entschieden, weil sich herausstellt, dass die Befehle in ARM überschaulicher sind, was erheblich zu einem besseren Lerneffekt beitragen kann.
ChaOS Architecture
Überblick
ChaOS ist mein kleines Betriebssystem, welches ich für mein Studium entwickle. Es soll mir dabei helfen, die Konzepte eines Betriebssystem durch Praxis zu verinnerlichen. Ich werde mich darauf konzentrieren, die rudimentären Dinge einzubauen, damit es realitätsnah an echten modernen Betriebssystemen ist.
Architektur und Designentscheidungen
Warum ARM?
Ich habe mich für ARM entschieden, weil sich herausstellt, dass die Befehle in ARM überschaulicher sind, was erheblich zu einem besseren Lerneffekt beitragen kann.
Warum GRUB?
GRUB erleichtert den Boot-Process, da ich mich nicht um das laden des Betriebssystems kümmern muss.
Warum Microkernel?
Ein Mikrokernel wird als die sauberste Lösung für Betriebssysteme gesehen in der Hinsicht, dass der Kernel so klein wie möglich gehalten wird, womit Sicherheitslücken und Anfälligkeit für Probleme minimiert wird. Jedoch ist auch wichtig zu wissen, dass die Performance von Micro-Kerneln nicht so gut ist, da mehr Kommunikation für Treiber und Dateisystem Beispielsweise entsteht, da diese nicht Teil des Kernels sind
Warum POSIX-Schnittstellen?
POSIX hat den Vorteil, dass sich das System sehr lange bewährt hat und somit die Schnittstellen bereits einen sehr soliden Werkzeugkasten für mein kleines System bilden.
Prozessverwaltung
Mein Prozess soll durch einen Struct definiert werden, das vereinfacht den Umgang damit erheblich. Daher, dass die Komplexität meines Betriebssystem überschaubar bleiben sollte, nehme ich hierzu erst einmal eine Liste für das Durchgehen der Prozesse. Bei schlechter Performance werde ich ein neues System überlegen. Prozesse sollen auch mit Prioritäten versehen sein. Damit die Prozesse zwischeneinander kommunizieren können, wie zum Beispiel für die Dateierstellung an das VFS, benötigen wir eine IPC. Wie die IPC aussieht muss ich mir noch ausarbeiten.
Dateisystemverwaltung
Ich möchte ein VFS implementieren, damit ich Daten persistent abspeichern kann. Ziel ist, dass ich die Daten in einem eigenen VFS-Format speichern kann.
Shell
Es soll eine erste Shell geben namens Mocha. Mocha soll eine einfache Shell werden, welche den CWD kennt, Streams umleiten kann mit > >> | . Relative Pfade sollen ebenso möglich sein.
Standard-Library
Eine kleine Standardbibliothek erstelle ich noch, damit man in der Lage ist die Prozesse korrekt vom Kernel zu isolieren.
Boot-Sequenz
Der Ablauf sollte wie folgt aussehen:
QEMU lädt Kernel direkt Assembly: Stack einrichten, CPU-Modus setzen C-Code: kernel_main()
Komponenten
Kernel
- Main
- Prozessverwaltung
- IPC
- PMM (Physical Memory Manager)
- Scheduler
- Spinlocks
- Actions (Shutdown/Restart)
- Privilegierung, Unterscheidung Kernel und Nutzer
VFS
- Dateisystemverwaltung
- Dateiformat
Shell
- Name: Mocha
Standard-Library
- User-Library (UserKit)
- Kernel-Library (KernelKit)
Abläufe in ChaOS
Beispiel Shell
Mocha (Shell) ↓ UserKit ↓ Syscalls Kernel ↓ KernelKit Hardware (ARM)
Warum Microkernel?
Ein Mikrokernel wird als die sauberste Lösung für Betriebssysteme gesehen in der Hinsicht, dass der Kernel so klein wie möglich gehalten wird, womit Sicherheitslücken und Anfälligkeit für Probleme minimiert wird. Jedoch ist auch wichtig zu wissen, dass die Performance von Micro-Kerneln nicht so gut ist, da mehr Kommunikation für Treiber und Dateisystem Beispielsweise entsteht, da diese nicht Teil des Kernels sind
Warum POSIX-Schnittstellen?
POSIX hat den Vorteil, dass sich das System sehr lange bewährt hat und somit die Schnittstellen bereits einen sehr soliden Werkzeugkasten für mein kleines System bilden.
Prozessverwaltung
Mein Prozess soll durch einen Struct definiert werden, das vereinfacht den Umgang damit erheblich. Daher, dass die Komplexität meines Betriebssystem überschaubar bleiben sollte, nehme ich hierzu erst einmal eine Liste für das Durchgehen der Prozesse. Bei schlechter Performance werde ich ein neues System überlegen. Prozesse sollen auch mit Prioritäten versehen sein. Damit die Prozesse zwischeneinander kommunizieren können, wie zum Beispiel für die Dateierstellung an das VFS, benötigen wir eine IPC. Wie die IPC aussieht muss ich mir noch ausarbeiten.
Dateisystemverwaltung
Ich möchte ein VFS implementieren, damit ich Daten persistent abspeichern kann. Ziel ist, dass ich die Daten in einem eigenen VFS-Format speichern kann.
Shell
Es soll eine erste Shell geben namens Mocha. Mocha soll eine einfache Shell werden, welche den CWD kennt, Streams umleiten kann mit > >> | . Relative Pfade sollen ebenso möglich sein.
Standard-Library
Eine kleine Standardbibliothek erstelle ich noch, damit man in der Lage ist die Prozesse korrekt vom Kernel zu isolieren.
Boot-Sequenz
- QEMU lädt Kernel bei Adresse 0x40000000 (ARM virt machine)
- Assembly (_start):
- Stack Pointer setzen
- Von EL2 nach EL1 wechseln
- BSS-Segment nullen
- kernel_main() aufrufen
- C-Code (kernel_main()):
- UART initialisieren (Ausgabe)
- PMM initialisieren
- Scheduler initialisieren
- VFS als Prozess starten
- Mocha als Prozess starten
Komponenten
Kernel
- Main
- Prozessverwaltung
- IPC
- PMM (Physical Memory Manager)
- Scheduler
- Spinlocks
- Actions (Shutdown/Restart)
- Privilegierung, Unterscheidung Kernel und Nutzer
VFS
- Dateisystemverwaltung
- Dateiformat
Shell
- Name: Mocha
Standard-Library
- User-Library (UserKit)
- Kernel-Library (KernelKit)
Abläufe in ChaOS
Beispiel Shell
Mocha (Shell) ↓ UserKit ↓ Syscalls Kernel ↓ KernelKit Hardware (ARM)