rou2exOS - un OS de loisir de type DOS écrit en Rust et en assembleur x86

• Système d’exploitation 64 bits de style DOS développé en Rust, avec un peu d’assembleur x86 également utilisé pour le chargement du noyau
• Implémente le mode texte VGA (80x25), le système de fichiers FAT12 et une pile réseau IPv4 via SLIP (ICMP/UDP/TCP/HTTP)
• Exécuté et développé sur une machine virtuelle basée sur QEMU, avec prise en charge partielle de véritables supports disquette
• Inclut des utilitaires de base comme un éditeur de texte, l’autocomplétion TAB pour fichiers/répertoires, le jeu Snake, etc.

Architecture et chargeur de démarrage

• Le CPU cible est x86_64, avec un support futur prévu pour l’architecture ARM (aarch)
• Les premières versions chargeaient et exécutaient le noyau en mémoire via un bootloader écrit à la main
• Sur le noyau 64 bits, le bootloader GRUB2 est utilisé pour gérer l’entrée en Long Mode et la transition depuis le Protected Mode
• Le bootloader stage2 effectue notamment la configuration de la GDT, de l’IDT, de la pagination et l’attribution du pointeur Multiboot2
• Le noyau se compose d’un interpréteur de commandes shell et de divers composants personnalisés

Émulation et images dans QEMU

• Le développement et les tests sont réalisés dans un environnement de machine virtuelle via QEMU
• Création d’images ISO : utilisation de grub2-mkrescue et xorriso
• Prise en charge de la création et du montage d’images de disquette FAT12, utilisables sur du matériel réel ou via le drapeau QEMU -fda fat.img

Procédure d’initialisation

• À l’entrée dans le noyau, vérification du Long Mode, des tags Multiboot2, du système de fichiers FAT12, de l’état VGA, etc.
• Après l’affichage d’un logo en ASCII art, le contrôle est transmis à la boucle du shell

Système de fichiers

• Prise en charge du système de fichiers FAT12 : lecture/écriture/recherche/suppression de fichiers, création/suppression de répertoires, etc.
• Création et écrasement de fichiers texte, avec prise en charge des sous-répertoires
• Inclut une fonction de vérification de cohérence du système de fichiers avec l’outil fsck
• La prise en charge de FAT32 est également prévue par la suite

Pile réseau

• Envoi et réception de paquets IPv4 sur la base du protocole SLIP
• Prise en charge du traitement des trames Ethernet (tests non terminés)
• Prise en charge de ICMP Echo (Request/Reply), d’UDP et de TCP (machine à états SYN/SYNACK)
• Serveur HTTP simple : diffusion de pages HTML statiques

Jeu Snake

• Jeu Snake intégré, avec une future version multijoueur (P2P TCP) également prévue
• Les données du jeu (niveaux, score) peuvent être sauvegardées et rechargées sous forme de fichiers texte
• Touche ESC pour quitter la partie, avec enregistrement du meilleur score selon le résultat

Intérêt du projet et points d’usage

• En tant qu’exemple de système d’exploitation écrit en Rust, il permet de mieux percevoir les gains en sécurité et en productivité dans le développement logiciel bas niveau
• Grâce aux tests SLIP/ICMP, à un déploiement simple et à la prise en charge de machines réelles, il convient bien à l’expérimentation autour des OS et à l’apprentissage d’implémentations personnalisées
• Il permet de découvrir directement une architecture de système de type DOS combinant Rust et assembleur x86

[GN⁺]

Commentaires sur Hacker News

• Utilisation d’un langage garantissant la sûreté mémoire, base x86_64 avec prise en charge d’Arm prévue, pile réseau maison, démarrage possible par CD et multiboot ; mon projet hobby offre une expérience qui surpasse DOS
  • Pour rivaliser avec DOS, il faut impérativement pouvoir exécuter Doom et BASIC ; c’est officiellement la ligne de base d’un système de style DOS
  • Un mélange de Rust et d’assembleur x86, donc si l’objectif est la sûreté mémoire, on peut se demander quelle en est vraiment la valeur pratique ; aujourd’hui, Rust donne parfois l’impression d’être survendu comme l’était l’impression 3D à une époque ; dans sa démocratisation, les gains concrets semblent limités, et ce serait bien si le projet était compatible avec des logiciels anciens, mais sinon cela reste plus proche d’un projet éducatif ou de passionné ; on a l’impression qu’il est encore loin d’un usage réel
• J’aime beaucoup le fait qu’ils utilisent SLIP et slattach(1) dans la pile réseau ; quand j’ai moi-même écrit une petite pile TCP/IP, j’avais aussi relié le noyau via une connexion SLIP sur un pty sous Linux ; il y avait autrefois slattach(1) sur macOS aussi, mais il semble avoir été supprimé ; je me demande si quelqu’un a déjà utilisé SLIP sur macOS pour créer une API réseau cross-platform ; comme alternatives, il y a tun/tap sous Linux et utun sur macOS, mais SLIP est bien plus simple
• Je me demande pourquoi ils ont choisi x86 : parce qu’il y a beaucoup de ressources, à cause du format d’instructions particulier, de la complexité de la séquence de boot, ou parce qu’ils cherchent à reprendre DOS tel quel ? Ils disent aussi que l’architecture ARM sera bientôt prise en charge, mais comme DOS relie étroitement matériel et logiciel, je me demande comment ils comptent gérer le support de plusieurs architectures
  • Je n’ai pas regardé ce projet directement, mais je suppose que la plateforme x86 intègre historiquement énormément d’interfaces grâce à la compatibilité legacy, ce qui facilite la mise en œuvre d’un « OS de type DOS » très mince et simple ; pas besoin de parser un device tree, de configurer la MMU, ni de gérer des bus complexes comme PCI(e), donc on peut démarrer simplement ; sur ARM, le bootstrap est lui-même difficile, et il faut accepter davantage de contraintes pour garder cette simplicité ; ce qu’on peut faire sans MMU est limité, et il n’y a pas d’interface BIOS, donc on ne peut pas lire des secteurs ou attendre une touche aussi simplement que sur x86
  • Le choix de x86 vient du fait que ce système dérive d’une première version créée en Turbo C sur la base des interruptions BIOS et d’assembleur inline ; l’objectif n’est pas simplement d’imiter MS-DOS, même si le projet s’en inspire beaucoup ; le support de plusieurs architectures est rendu envisageable grâce à la possibilité, dans le compilateur Rust, de spécifier l’architecture cible ; il suffit de définir la cible avant le build, et cela s’applique directement pendant la compilation
• Dans l’environnement UEFI actuel, avec son shell, une solution 64 bits de type DOS basée sur le FLOSS aurait peut-être été préférable ; ce serait sympa comme boot manager rétro ou comme outil de diagnostic système ; je me demande si cela peut s’exécuter depuis la partition système EFI ; je vois que FAT12 est pris en charge, mais qu’en est-il du GPT ? Et je me demande si l’affichage contrôle directement le matériel vidéo ou s’il s’agit d’une sortie de type terminal
  • Le démarrage depuis une partition système EFI n’a pas encore été testé ; seul le système de fichiers FAT12 est officiellement pris en charge pour l’instant (il existe une fonction de disque en mémoire, mais elle ne marche pas actuellement) ; le GPT n’est pas pris en charge pour le moment ; la prise en charge de FAT32 est envisagée en priorité (les clés USB utilisent généralement FAT32) ; pour la dernière question, l’OS écrit directement dans le tampon mémoire VGA, et GRUB fournit une résolution 80x25
• Je trouve ce projet très sympa ; dommage qu’ils aient raté la réplique culte : « ce n’est qu’un hobby, ça ne deviendra jamais gros et professionnel comme Linux »
• Je me demande s’il est prévu de prendre en charge les signes diacritiques tchèques
  • Pour cette version, seule la langue anglaise est prévue ; la première version avait d’abord été créée en tchèque
• Je me demande s’ils utilisent un pilote VGA entièrement réécrit en Rust
  • Ce module contient les sources liées au VGA
  • C’est plus ou moins ça, mais en pratique c’est surtout un module wrapper autour de l’accès au tampon vidéo
• Question : c’est bien de style DOS, mais sans compatibilité avec DOS ?
  • C’est une analyse correcte ; la première version était en 16 bits et conçue pour être presque compatible avec MS-DOS, et j’estime qu’on peut aussi la ranger dans la catégorie des systèmes DOS au sens large dès lors qu’elle gère au minimum des E/S disque simples
  • Autrement dit, au sens d’un niveau de compatibilité MS-DOS permettant d’exécuter Alley Cat, Dune 2 ou Doom
• Avis qu’il faudrait une file d’événements pour prendre en charge un runtime asynchrone
  • Demande d’avis sur l’implémentation d’une boucle d’événements aboutie
• Question amusante sur la possibilité d’exécuter Crysis