- TacOS est un OS hobbyiste de type UNIX-like, basé sur un noyau maison écrit from scratch en C et en assembleur, capable d’exécuter DOOM et plusieurs petits programmes en espace utilisateur
- Le noyau inclut VFS, un ordonnanceur, TempFS, les périphériques, le changement de contexte, la gestion de la mémoire virtuelle, l’allocation de cadres de pages physiques, ainsi qu’un portage de Doom
- L’environnement d’exécution prend en charge à la fois le matériel réel et l’émulateur Qemu, avec des tests sur matériel réel effectués sur l’ordinateur portable de l’auteur
- La compilation et l’exécution démarrent après
git clone, avec make run, et nécessitent l’installation de Xorriso, Qemu, NASM et Clang
- TacOS n’est pas un OS suffisamment abouti pour un usage réel ; c’est un toy OS hobbyiste avec plusieurs bugs connus
Présentation de TacOS
- TacOS est un OS écrit from scratch en C et en assembleur, avec son propre noyau
- Il s’appuie sur un noyau de type UNIX-like et peut exécuter DOOM ainsi que plusieurs petits programmes en espace utilisateur
- Ses principaux composants sont les suivants
- VFS
- ordonnanceur
- TempFS
- périphériques
- changement de contexte
- gestion de la mémoire virtuelle
- allocation de cadres de pages physiques
- portage de Doom
Environnement d’exécution et limites
- TacOS peut s’exécuter sur du matériel réel ainsi que dans l’émulateur Qemu
- Les tests sur matériel réel ont été effectués sur l’ordinateur portable de l’auteur
- Le projet n’est pas un OS finalisé et réellement exploitable, mais un toy OS hobbyiste
- Il comporte plusieurs bugs connus
Démarrage rapide
- La compilation et l’exécution peuvent se faire avec la commande suivante
git clone https://github.com/UnmappedStack/TacOS
cd TacOS && make run
make run compile TacOS et le lance automatiquement dans l’émulateur Qemu- Les outils requis sont les suivants
Commandes de build
make run : compile TacOS et l’exécute dans Qemumake qemu : exécute TacOS déjà compilé dans Qemumake disk : génère l’image disque complète sous tacos.isomake kernel : compile le noyau TacOS, cœur du systèmemake libc : compile la bibliothèque standardmake userspace : compile les applications en espace utilisateurmake initrd : crée le ramdisk initial utilisé au démarrage du systèmemake lint : exécute les règles du linter sur le noyaumake qemu-gdb : lance TacOS dans Qemu avec GDB attaché
Débogage
- Pour attacher GDB pendant les tests de TacOS, exécutez
make qemu-gdb, puis connectez-vous à la cible distante GDB depuis un autre terminal
$ gdb -q
(gdb) target remote :1234
(gdb) file kernel/bin/tacos
(gdb) continue
- Pour déboguer le noyau, utilisez
kernel/bin/tacos
- Pour déboguer un programme en espace utilisateur, utilisez
initrd/usr/bin/<program>
Licence et règles de contribution
- TacOS utilise la Mozilla Public License 2.0
- Les contributions sont ouvertes, mais il faut créer une issue et se faire attribuer la modification avant toute pull request
- Les pull requests contenant uniquement des corrections simples de fautes ou de grammaire ne seront pas fusionnées
- Les messages de commit doivent suivre le format
[component] change
- Les pull requests qui regroupent en un seul énorme commit des milliers de lignes modifiant plusieurs composants sans lien ne seront pas revues
Communauté
- Il existe un serveur Discord pour les mises à jour liées à TacOS, l’aide sur les projets OSDev et les échanges
1 commentaires
Commentaires sur Hacker News
Félicitations ! Tu dois être fier, et choisir DOOM comme preuve de concept est une bonne idée.
Je risque de casser l’ambiance avec des questions de débutant, mais je me demande quelles étapes seraient nécessaires pour l’exécuter sur un ordinateur portable.
Après l’avoir compilé, est-ce que le processus ressemble à la configuration d’un dual boot sur un PC Windows ? C’est assez drôle de demander à un inconnu sur Internet comment lancer un logiciel potentiellement risqué sur mon ordinateur.
Je serais aussi curieux de savoir s’il y a des manuels ou lectures que tu recommanderais à quelqu’un qui voudrait essayer ce genre de projet. J’ai suivi des cours de systèmes d’exploitation et de matières liées à l’université, mais comme je venais de l’électronique/électrotechnique, tout était très abstrait et centré sur les concepts. J’aimerais des ressources plus concrètes, et ce n’est pas forcément obligé d’être du x64.
Si tu veux écrire un kernel, je te recommande de commencer par https://osdev.wiki, et de lire aussi les spécifications pertinentes comme l’Intel Developer Manual, ainsi que les spécifications des pilotes que tu écriras toi-même.
Je ne connais pas très bien le développement de kernels hors x86, mais à ma connaissance les concepts sont pour la plupart les mêmes, seule l’implémentation technique change. Le README du projet contient un lien vers un serveur Discord, où il y a beaucoup de gens vraiment brillants qui seront ravis d’aider.
C’est sympa, mais est-ce que ton taco peut aussi faire tourner DOOM ?
Blague à part, c’est vraiment un effort louable, bravo ! Ce que je me demande, c’est si, en créant TacOS, tu as pris DOOM comme objectif standard, ou si le but était dès le départ de créer un système d’exploitation dédié qui ne ferait tourner que DOOM.
Je pose la question par pure curiosité. Il y a presque 30 ans, j’avais créé pour apprendre et m’amuser un système d’exploitation extrêmement rudimentaire qui se contentait de booter ; un système dédié, portable partout et capable en pratique uniquement de lancer DOOM rendrait le mème « est-ce que ça fait tourner DOOM ? » encore plus ironique et amusant.
Super boulot, j’espère que tu continueras.
Faire tourner Doom lui-même m’a pris environ une semaine, y compris l’ajout des exigences libc, mais il y avait beaucoup plus de travail de fond déjà en place auparavant.
J’ai utilisé DoomGeneric, qui est en gros un fork de Doom conçu pour être très portable. J’espère que ça répond à ta question, même si j’ai peut-être mal compris.
Passer directement d’un kernel écrit from scratch à DOOM, c’est presque une certification de hacker de très haut niveau. Le voir tourner sur du vrai matériel doit être vraiment gratifiant, et c’est super classe.
C’est un peu tangent, mais je me posais une question similaire. Je me demande s’il y a eu beaucoup de tentatives de créer des jeux qui bootent directement sur du matériel PC moderne.
L’idée serait d’entrer directement dans le jeu sans charger un système d’exploitation complet, un peu comme les consoles de jeux des générations précédentes. Pour garder les choses simples, le Wi-Fi, le Bluetooth ou le GPU seraient difficiles à exploiter sans pilotes modernes, mais le clavier et la souris semblent assez faisables grâce à des accès BIOS de base. Les termes ne sont peut-être pas les bons, mais j’espère que l’idée passe.
Si tu ne veux pas toucher aux entrées/sorties disque, la grosse limite est 512 octets ou moins. En pratique, tu exécutes ton programme comme master boot record. Si tu as besoin de plus d’espace, il faut lire quelques LBA depuis le disque ; il existe des interruptions pour ça, et osdev contient aussi de meilleures ressources.
À part ça, les différences entre un fichier .com, avec généralement une limite de segment unique de 64 Ko, et un programme bootable de style MBR sont assez faibles.
Vraiment beau travail. J’aimerais avoir le niveau pour faire ce genre de chose, mais il a dû falloir lire beaucoup de spécifications, et c’est mon plus gros point faible.
Question peut-être bête, mais si l’on voulait utiliser l’accélération GPU, même sous une forme très minimale, à quel point serait-il difficile d’écrire un pilote GPU ? Est-ce que la documentation est bonne selon toi ?
Le GPU émulé de Qemu est assez bien documenté, donc ce serait peut-être possible, mais pour quelque chose comme les GPU Nvidia, la documentation est mauvaise et, jusqu’à récemment, elle était totalement fermée. Linux souffre aussi de ce problème, et j’ai vu quelques développeurs d’OS hobbyistes finir par reprendre les pilotes GPU de Linux.
Il n’y a pas beaucoup de choses que je classerais comme presque impossibles, mais écrire un pilote GPU vraiment correct pour un GPU courant n’est franchement pas quelque chose que je me vois capable de faire un jour.
Salut unmapped, sur GitHub et Discord j’utilise ThatOSDeveloper, c’est mon nom d’affichage. Je ne savais pas que tu avais fait tourner Doom sur TacOS, c’est plutôt cool.
J’ai quelques questions : est-ce le Doom original, est-il sur le disque ou dans l’initramfs, et est-ce que tu utilises Freedoom avec ton moteur, ou le WAD shareware de Doom ?
C’est très cool, mais de nos jours il existe des langages bas niveau avec sûreté mémoire ; je me demande donc pourquoi tu as choisi un langage non sûr. On sait déjà tous que la plupart des bugs de sécurité sont liés à la mémoire.
Je comprends que ce soit un projet hobby, mais je ne comprends pas pourquoi on ne met pas les langages non sûrs à la retraite alors qu’il existe de meilleures alternatives.
J’ai utilisé Rust sur d’autres projets, mais pour le développement de kernel, j’ai vraiment l’impression de préférer largement un langage simple et lisible à un langage sûr.
Bienvenue au club ! J’ai fait quelque chose de presque identique, et j’ai vraiment apprécié la sérénité qu’il y a à construire quelque chose qui ne deviendra absolument jamais un produit.
https://jakobbr.eu/2024/08/19/writing-my-own-x86_64-operatin...
Projet vraiment génial ! Je me demande comment TacOS gère l’isolation des processus et l’ordonnancement.
Il y a un ordonnanceur round-robin relié au pilote PIT : toutes les 10 ms, le PIT déclenche une interruption et l’ordonnanceur s’exécute. L’ordonnanceur choisit la tâche suivante, enregistre l’état courant de la tâche précédente, bascule vers le nouvel espace d’adressage, change de pile, restaure les registres de la tâche, puis passe en mode utilisateur ring 3 avec l’instruction iretq tout en sautant vers le pointeur d’instruction.
J’aimerais en savoir plus sur TacOS. Comment gère-t-il l’exécution sûre de plusieurs programmes en même temps ?
L’introduction vaut aussi la peine d’être lue : https://pages.cs.wisc.edu/~remzi/OSTEP/dialogue-virtualizati...
https://wiki.osdev.org/ contient des détails de plateforme et d’autres ressources.