- TacOS ist ein selbst entwickeltes UNIX-ähnliches Hobby-OS auf Basis eines eigenen Kernels, das von Grund auf in C und Assembler geschrieben wurde und DOOM sowie mehrere kleine Userspace-Programme ausführen kann
- Der Kernel umfasst VFS, einen Scheduler, TempFS, Geräte, Context Switching, Verwaltung des virtuellen Speichers, Zuweisung physischer Seitenrahmen und einen Doom-Port
- Die Laufzeitumgebung unterstützt sowohl echte Hardware als auch den Qemu-Emulator; auf echter Hardware wurde auf dem Laptop des Entwicklers getestet
- Build und Start beginnen nach
git clone mit make run; benötigt werden Xorriso, Qemu, NASM und Clang
- TacOS ist nicht für den realen Einsatz ausgereift, sondern ein toy OS für Hobbyzwecke mit mehreren bekannten Bugs
Überblick über TacOS
- TacOS ist ein from-scratch entwickeltes OS, geschrieben in C und Assembler, mit eigenem Kernel
- Es ist als UNIX-ähnlicher Kernel aufgebaut und kann DOOM sowie mehrere kleine Userspace-Programme ausführen
- Zu den wichtigsten Komponenten gehören
- VFS
- Scheduler
- TempFS
- Geräte
- Context Switching
- Verwaltung des virtuellen Speichers
- Zuweisung physischer Seitenrahmen
- Doom-Port
Laufzeitumgebung und Grenzen
- TacOS kann auf echter Hardware und im Qemu-Emulator ausgeführt werden
- Die Tests auf echter Hardware wurden auf dem Laptop des Entwicklers durchgeführt
- Das Projekt ist kein ausgereiftes, produktiv nutzbares OS, sondern ein toy OS für Hobbyzwecke
- Es gibt mehrere bekannte Bugs
Schnellstart
- Build und Ausführung sind mit den folgenden Befehlen möglich
git clone https://github.com/UnmappedStack/TacOS
cd TacOS && make run
make run baut TacOS und startet es automatisch im Qemu-Emulator- Benötigte Werkzeuge sind
Build-Befehle
make run: baut TacOS und führt es in Qemu ausmake qemu: führt das bereits gebaute TacOS in Qemu ausmake disk: baut das vollständige Disk-Image als tacos.isomake kernel: baut den TacOS-Kernel als Kern des Systemsmake libc: baut die Standardbibliothekmake userspace: baut die Userspace-Anwendungenmake initrd: erstellt die initiale RAM-Disk, von der das System bootetmake lint: führt die Linter-Regeln für den Kernel ausmake qemu-gdb: startet TacOS in Qemu mit angeschlossenem GDB
Debugging
- Um während des Testens von TacOS GDB anzuhängen,
make qemu-gdb ausführen und dann in einem anderen Terminal eine Verbindung zum entfernten GDB-Ziel herstellen
$ gdb -q
(gdb) target remote :1234
(gdb) file kernel/bin/tacos
(gdb) continue
- Beim Debuggen des Kernels
kernel/bin/tacos angeben
- Beim Debuggen von Userspace-Programmen
initrd/usr/bin/<program> angeben
Lizenz und Beitragsregeln
- TacOS verwendet die Mozilla Public License 2.0
- Beiträge sind willkommen, aber vor einem Pull Request muss ein Issue eröffnet und die Änderung zugewiesen werden
- Pull Requests, die nur einfache Tipp- oder Grammatikfehler korrigieren, werden nicht gemergt
- Commit-Messages müssen dem Format
[component] change folgen
- Pull Requests mit tausenden Zeilen Änderungen in mehreren nicht zusammenhängenden Komponenten, zusammengefasst in einem einzigen riesigen Commit, werden nicht begutachtet
Community
- Es gibt einen Discord-Server für Updates zu TacOS, Hilfe bei OSDev-Projekten und zum Austausch
1 Kommentare
Meinungen auf Hacker News
Glückwunsch! Du musst stolz sein, und DOOM als Proof of Concept zu wählen, ist auch eine gute Wahl.
Das sind vielleicht nur Anfängerfragen und nehmen etwas den Wind aus den Segeln, aber ich frage mich, welche Schritte nötig wären, um das auf einem Laptop auszuführen.
Ist das nach dem Build so ähnlich wie das Einrichten von Dual Boot auf einem Windows-PC? Irgendwie lustig, dass ich einen Fremden aus dem Internet frage, wie ich gefährliche Software auf meinem Computer ausführen kann.
Wenn man so ein Projekt ausprobieren möchte: Gibt es Lehrbücher oder Lesestoff, die du empfehlen würdest? Ich habe an der Uni Betriebssysteme und verwandte Fächer belegt, aber als Elektrotechnik-Student war das alles sehr abstrakt und konzeptorientiert. Konkreteres Material wäre schön, und es muss nicht unbedingt x64 sein.
Wenn du einen Kernel schreiben willst, würde ich empfehlen, zuerst https://osdev.wiki anzuschauen, außerdem relevante Spezifikationen wie das Intel Developer Manual sowie die Spezifikationen der Treiber, die du selbst schreiben willst.
Mit Kernel-Entwicklung außerhalb von x86 kenne ich mich nicht wirklich aus, aber soweit ich weiß, sind die Konzepte größtenteils gleich, nur die technische Umsetzung unterscheidet sich. Im Projekt-README gibt es einen Link zu einem Discord-Server; dort sind viele wirklich kluge Leute, die sicher gern helfen.
Schön und gut, aber kann dein Taco auch DOOM ausführen?
Spaß beiseite: Das ist wirklich eine lobenswerte Leistung, gut gemacht! Was mich interessiert: War DOOM beim Bau von TacOS so etwas wie ein Standardziel, oder war es von Anfang an das Ziel, ein dediziertes Betriebssystem zu bauen, das nur DOOM ausführt?
Ich frage aus reiner Neugier. Vor fast 30 Jahren habe ich zum Lernen und aus Spaß einmal ein extrem rudimentäres Betriebssystem gebaut, das gerade so booten konnte. Ein portables Spezialbetriebssystem, das im Grunde nur DOOM ausführen kann, würde das Meme „Läuft darauf DOOM?“ noch viel ironischer und lustiger machen.
Tolle Arbeit, bitte mach weiter.
Doom selbst zum Laufen zu bringen, einschließlich zusätzlicher libc-Anforderungen, hat ungefähr eine Woche gedauert; davor steckte aber deutlich mehr Vorarbeit in der Grundlage.
Ich habe DoomGeneric verwendet, im Grunde ein sehr portabel gemachter Doom-Fork. Ich hoffe, das beantwortet die Frage; vielleicht habe ich sie auch falsch verstanden.
Von einem selbst geschriebenen Kernel direkt zu DOOM zu kommen, ist so etwas wie ein Hacker-Nachweis der Spitzenklasse. Es auf echter Hardware laufen zu sehen, muss wirklich erfreulich sein; sehr cool.
Etwas am Rande, aber ich habe mich Ähnliches gefragt: Ob es wohl viele Versuche gab, Spiele zu bauen, die direkt auf moderner PC-Hardware booten.
Also direkt ins Spiel, ohne ein ganzes Betriebssystem hochzufahren, ähnlich wie bei älteren Spielkonsolen. Um es einfach zu halten, wären Dinge wie WLAN, Bluetooth und GPU ohne moderne Treiber wohl schwer nutzbar, aber Tastatur und Maus wirken mit grundlegenden BIOS-Zugriffen ziemlich machbar. Die Begriffe sind vielleicht nicht ganz korrekt, aber ich hoffe, der Kern kommt rüber.
Wenn du dich nicht mit Disk-I/O beschäftigen willst, ist die große Einschränkung 512 Byte oder weniger. Im Grunde führst du das Programm als Master Boot Record aus. Wenn du mehr Platz brauchst, musst du ein paar LBAs von der Platte lesen; dafür gibt es Interrupts, und osdev hat dazu bessere Materialien.
Ansonsten sind die Unterschiede zwischen einer .com-Datei, der üblichen 64-KB-Einsegment-Beschränkung, und einem MBR-artigen bootfähigen Programm ziemlich klein.
Wirklich tolle Arbeit. Ich wünschte, ich hätte die Fähigkeiten für so etwas, aber dafür musste man sicher viele Spezifikationen lesen, und genau das ist meine größte Schwäche.
Vielleicht eine dumme Frage, aber wenn man GPU-Beschleunigung auch nur in sehr kleiner Form nutzen wollte: Wie schwierig wäre es, einen GPU-Treiber zu schreiben? Sind die relevanten Dokumente deiner Meinung nach gut?
Die emulierte GPU von Qemu ist recht ordentlich dokumentiert, damit könnte es möglich sein. Aber bei Dingen wie Nvidia-GPUs ist die Dokumentation schlecht, und bis vor Kurzem war sie komplett nicht öffentlich. Linux kämpft ebenfalls damit, und ich habe einige Hobby-OS-Entwickler gesehen, die am Ende einfach Linux-GPU-Treiber übernehmen.
Es gibt nicht viele Dinge, die ich als nahezu unmöglich markiert habe, aber einen wirklich brauchbaren GPU-Treiber für gängige GPUs zu schreiben, ist ehrlich gesagt nichts, von dem ich glaube, dass ich es eines Tages schaffen werde.
Hallo unmapped, ich bin auf GitHub und Discord als ThatOSDeveloper unterwegs, das ist mein Anzeigename. Ich wusste nicht, dass TacOS Doom ausführen kann; ziemlich cool.
Ich habe ein paar Fragen: Ist es das originale Doom, liegt es auf der Disk oder in initramfs, und nutzt du zusammen mit der Engine Freedoom oder das Shareware-Doom-WAD?
Sehr cool, aber heutzutage gibt es Low-Level-Sprachen mit Speichersicherheit; warum also eine unsichere Sprache wählen? Wir wissen alle längst, dass die meisten Sicherheitsbugs speicherbezogen sind.
Ich verstehe, dass es ein Hobbyprojekt ist, aber wenn es bessere Alternativen gibt, verstehe ich nicht, warum wir unsichere Sprachen nicht ausmustern.
Ich habe in anderen Projekten Rust verwendet, aber bei der Kernel-Entwicklung habe ich stark das Gefühl, dass ich viel lieber eine einfache, gut lesbare Sprache nutzen möchte als eine sichere Sprache.
Willkommen im Club! Ich habe fast dasselbe gemacht und die Gelassenheit, etwas zu bauen, das garantiert niemals zu einem Produkt wird, wirklich genossen.
https://jakobbr.eu/2024/08/19/writing-my-own-x86_64-operatin...
Wirklich cooles Projekt! Mich würde interessieren, wie TacOS Prozessisolation und Scheduling handhabt.
Es gibt einen Round-Robin-Scheduler, der an den PIT-Treiber gekoppelt ist: Alle 10 ms löst der PIT einen Interrupt aus und der Scheduler läuft. Der Scheduler wählt die nächste Aufgabe aus, speichert den aktuellen Zustand der vorherigen Aufgabe, wechselt in den neuen Adressraum, tauscht den Stack, stellt die Register der Aufgabe wieder her und wechselt dann mit der Anweisung iretq in den Ring-3-User-Mode, wobei er zum Instruction Pointer springt.
Ich würde gern mehr über TacOS erfahren. Wie verwaltet es das sichere gleichzeitige Ausführen mehrerer Programme?
Die Einleitung lohnt sich ebenfalls: https://pages.cs.wisc.edu/~remzi/OSTEP/dialogue-virtualizati...
Auf https://wiki.osdev.org/ gibt es Plattformdetails und weiteres Material.