HN en accès public : Banan-OS, un système d’exploitation de type Unix écrit à partir de zéro

 (github.com/Bananymous)
2 points par GN⁺ 2024-12-06 | 1 commentaires | Partager sur WhatsApp
  • Banan-OS est un système d’exploitation hobby écrit en C++, qui prend actuellement en charge les architectures x86_64 et i686
  • Son périmètre fonctionnel couvre l’espace utilisateur Ring3, le SMP, une pile réseau, le chargement ELF et l’édition de liens dynamique, la mémoire copy-on-write, ainsi qu’un environnement graphique de base
  • Côté pilotes et fonctions système, il prend en charge les disques NVMe et ATA, les NIC E1000/E1000E et de la famille RTL, les entrées PS2 et USB, les systèmes de fichiers Ext2 et FAT, GRUB et son propre bootloader BIOS
  • TCP est indiqué comme partiellement implémenté et bogué, tandis que SSL, les périphériques virtio, certains contrôleurs USB, les systèmes de fichiers Sys et 9P, ainsi que son propre bootloader UEFI ne sont pas encore implémentés
  • La compilation s’articule autour du script ./bos ; après la création de la toolchain, il permet d’exécuter QEMU ou Bochs, de compiler le noyau et les images, et de choisir les options d’architecture, de bootloader, d’UEFI et d’initrd

Présentation de Banan-OS

  • Banan-OS est un système d’exploitation hobby écrit en C++
  • Les architectures actuellement prises en charge sont x86_64 et i686
  • Une démo live est disponible sur bananymous.com/banan-os
  • Pour lancer DOOM, il faut entrer dans l’environnement GUI avec la commande start-gui, puis exécuter doom depuis le terminal GUI

Principales fonctionnalités implémentées

  • Fonctionnalités générales

    • Espace utilisateur Ring3

      • SMP, c’est-à-dire le multiprocesseur
      • Framebuffer linéaire basé sur VESA et GOP
      • Pile réseau
      • Chargement d’exécutables ELF
      • Interpréteur AML partiel
      • Environnement graphique de base
      • Émulateur de terminal
      • Barre d’état
      • Lanceur de programmes
      • Les « applis convenables » ne sont pas encore implémentées
      • Édition de liens dynamique ELF
      • Mémoire copy-on-write
      • Les mappings de fichiers sont implémentés
      • Les mappings anonymes ne sont pas implémentés

Prise en charge des pilotes, du réseau et des systèmes de fichiers

  • Pilotes
    • Prend en charge les disques NVMe ainsi que les disques ATA IDE/SATA
    • Prend en charge les NIC E1000, E1000E et RTL8111/8168/8211/8411
    • Le clavier PS2 prend en charge tous les jeux de scancodes, et la souris PS2 est également prise en charge
    • L’USB prend en charge xHCI, les claviers, les souris, le stockage de masse et les hubs
    • Les périphériques réseau et stockage EHCI, OHCI, UHCI et virtio ne sont pas implémentés
  • Réseau
    • Prend en charge ARP, ICMP, IPv4 et UDP

    • TCP est partiellement implémenté et comporte des bugs

      • Prend en charge les sockets de domaine Unix
      • SSL n’est pas implémenté
      • Systèmes de fichiers
      • Prend en charge le système de fichiers virtuel, Ext2, FAT12/16/32, Dev, Ram et Proc
      • Sys et 9P ne sont pas implémentés
      • Bootloader
      • Prend en charge GRUB et son propre bootloader BIOS
      • Son propre bootloader UEFI n’est pas encore implémenté

Structure du code

  • Chaque composant et bibliothèque majeur possède un sous-répertoire distinct, comme kernel, userspace ou libc
  • Chaque répertoire contient un répertoire include avec tous les fichiers d’en-tête du composant
  • Tous les en-têtes sont inclus via un chemin absolu

Compilation et exécution

  • Sur Ubuntu 22.04, les paquets apt nécessaires sont build-essential, git, ninja-build, texinfo, bison, flex, libgmp-dev, libmpfr-dev, libmpc-dev, parted, qemu-system-x86 et cpu-checker
  • Dans un environnement pacman, les paquets nécessaires sont base-devel, git, wget, cmake, ninja, parted et qemu-system-x86
  • La toolchain destinée au système d’exploitation ne se compile qu’une seule fois avec ./bos toolchain
    • La compilation de binutils et gcc peut prendre beaucoup de temps
  • La compilation et l’exécution de l’OS lui-même se font avec la commande ./bos
    • ./bos qemu
    • ./bos qemu-nographic
    • ./bos qemu-debug
    • ./bos bochs
  • Il est aussi possible de ne compiler que le noyau ou l’image disque
    • ./bos kernel
    • ./bos image
  • La création et la modification de l’image disque nécessitent des droits root

Options de compilation et gestion des images

  • Pour compiler pour une autre architecture, définissez la variable d’environnement BANAN_ARCH
    • Exemple : BANAN_ARCH=i686
  • Pour changer de bootloader, définissez la variable d’environnement BANAN_BOOTLOADER
    • Les valeurs prises en charge sont BANAN et GRUB
  • Pour l’exécuter en UEFI, il faut définir BANAN_UEFI_BOOT=1
    • OVMF_PATH doit également pointer vers le bon chemin OVMF ; la valeur par défaut est /usr/share/ovmf/x64/OVMF.fd
  • Pour créer une image initrd sans système de fichiers root physique, définissez BANAN_INITRD=1
    • Cela peut être utilisé pour tester sur du matériel doté de contrôleurs USB non pris en charge
  • Si l’image disque est corrompue ou si vous souhaitez en créer une nouvelle, supprimez build/banan-os.img ou exécutez ./bos image-full
  • Un script de shell completion pour zsh est également fourni
    • Copiez le fichier _script/shell-completion/zsh/_bos dans /usr/share/zsh/site-functions/, ou ajoutez _script/shell-completion/zsh au fpath de votre .zshrc

Modalités de contribution

  • Le dépôt upstream n’est pas hébergé sur GitHub, mais sur https://git.bananymous.com/Bananymous/banan-os
  • Il est aussi possible d’envoyer des PR GitHub, mais le maintainer devra télécharger le diff et l’appliquer manuellement
  • Il est possible d’obtenir un compte sur le serveur git séparé ; dans ce cas, il faut le contacter par e-mail ou sur Discord
  • Pour l’ajout de nouvelles fonctionnalités, il est préférable de contacter d’abord le maintainer
    • Comme il s’agit d’un projet à visée pédagogique, une PR envoyée sans consultation préalable pour une fonctionnalité que le maintainer comptait implémenter lui-même peut être fermée
    • Les corrections de bugs sont toujours les bienvenues
  • Les messages de commit doivent utiliser le format Subject: Description sur la première ligne
    • Subject indique la zone modifiée, comme Kernel, Shell ou BuildSystem
    • La première ligne doit tenir en 72 caractères
    • Le corps du message doit expliquer plus en détail les changements et leurs raisons
  • Tous les commits doivent passer les hooks pre-commit définis dans .pre-commit-config.yaml

À lire aussi

1 commentaires

 
GN⁺ 2024-12-06
Commentaires sur Hacker News

  • Vraiment génial, et j’aime beaucoup le nom. Je me demande quelle a été la partie la plus difficile à implémenter jusqu’ici, et s’il y a eu de sérieux obstacles en cours de route

    • Il n’y a pas eu de partie excessivement difficile, mais s’il faut en citer une, ce serait sans doute l’interpréteur AML ou la pile USB
      La spécification ACPI est tellement mal rédigée que l’interpréteur AML a été difficile, et l’USB a été pénible à cause de la taille de la spec et du grand nombre de renvois croisés
      Il n’y a pas eu de gros obstacle, mais pour certaines fonctionnalités, j’ai dû abandonner puis y revenir un ou deux mois plus tard
    • Au début, je lisais ça comme « banyan tree », puis je n’ai compris qu’en voyant l’ASCII art que c’était une référence à la banane

  • Vraiment impressionnant. Le fait d’avoir notamment implémenté les pilotes USB à partir de zéro est remarquable. Au passage, j’ai essayé de le casser avec cat doom1.wad

    • Merci. Il n’y a presque pas de sérialisation pour les données écrites sur le TTY, donc si on lui donne des données binaires arbitraires, ça peut se casser :D

  • Il y a une phrase qui, par convention, doit figurer dans toute annonce de nouveau noyau de système d’exploitation, et elle manque dans celle-ci

    • Tu parles sûrement de la phrase du genre : « c’est un projet hobby et ça ne sera ni gros ni professionnel comme GNU » ?

  • Génial. Je me demande combien d’heures par semaine tu consacres à ce projet. La quantité de travail investie a l’air énorme
    Ton profil dit que tu es étudiant ; est-ce que ça veut dire à l’université, et si oui, est-ce que tu as aussi travaillé directement sur cet OS dans le cadre de tes études ?

    • Oui, je suis bien étudiant à l’université. J’ai montré le projet à un professeur, ce qui m’a permis de « sauter » certains cours comme les systèmes d’exploitation ou la concurrence
      À part ça, le projet ne fait pas directement partie de mes études. En revanche, grâce à lui, j’ai aussi obtenu un travail à temps partiel côté embarqué à l’université
      Le temps investi varie vraiment selon ce qui se passe dans ma vie à ce moment-là. Certains mois, j’y ai passé en tout 5 heures, et certaines semaines, j’ai été proche des 40 heures

  • Super projet. PlatanOS pourrait aussi être un bon nom pour un fork

    • Je préfère PlátanOS, avec l’accent sur la première syllabe

  • Très bien, et ça a l’air d’avoir demandé énormément de travail. Je me demande quels ont été les défis les plus mémorables

    • Je pense que le plus gros défi, ça a été de lire de grosses spécifications. Je n’avais jamais vraiment fait ça avant, donc il m’a fallu du temps pour m’y habituer

  • Impressionnant. Je me demande comment tu développes concrètement : est-ce que tu l’exécutes dans une VM, sur du vrai matériel, et quand tu t’assois pour travailler, à quoi ressemble le processus ?
    Tu as dû énormément apprendre en faisant ça, donc je me demande aussi comment tu prends des notes ou suis le développement. Ou bien est-ce que l’OS lui-même sert un peu de journal de développement vivant ?

    • Environ 95 % des tests se font en VM. C’est beaucoup plus rapide et beaucoup plus pratique. Mais je teste quand même régulièrement sur du vrai matériel
      Voir tourner quelque chose sur du vrai bare metal est toujours génial, et le bare metal est bien moins indulgent qu’une VM
      En général, je choisis une fonctionnalité à ajouter, puis je parcours rapidement la spec correspondante, et je regarde aussi parfois comment les systèmes d’exploitation existants la gèrent. Une fois que j’ai un modèle mental de ce dont le système a besoin, j’écris le code au fil de ce qui me vient sur le moment
      J’ai la très mauvaise habitude de ne pas écrire de documentation ni de notes. En gros, je garde tout dans ma tête, puis j’oublie ces informations quand j’en ai besoin plus tard. Pour les choses plus complexes, je fais parfois des schémas et je prends des notes, mais elles restent presque toujours en local

  • Je me demande par où on commence, concrètement, pour écrire des pilotes comme NVMe, ATA ou Realtek NIC. Je sais que la souris et le clavier utilisent le standard HID, mais je me demande si les autres périphériques ont eux aussi des protocoles standard comparables
    Je me demande aussi si c’est pour ça que Linux peut éviter « l’installation de pilotes » dans la plupart des cas, et si des API de périphériques standard existent, pourquoi Windows passe-t-il par une procédure d’installation de pilote presque à chaque fois qu’on branche quelque chose ?

    • En gros, presque tous les périphériques courants ont des protocoles standardisés. Mais il existe aussi des périphériques pour lesquels le fabricant doit fournir un pilote
      Tous les périphériques pour lesquels j’ai écrit un pilote avaient une spécification disponible gratuitement. Par exemple, pour NVMe, c’est ici : https://nvmexpress.org/specifications
      Je ne sais pas vraiment comment Linux ou Windows gèrent les pilotes. Quand on compile le noyau Linux, on choisit quels pilotes inclure dans le noyau et lesquels laisser sous forme de modules. En général, les pilotes courants sont compilés avec le noyau, donc il n’y a presque jamais besoin de les installer plus tard ; il suffit de charger le module
      Il y a aussi des périphériques qui fonctionnent avec un pilote générique, mais qui offrent plus de fonctionnalités avec un pilote dédié. Par exemple, le réglage des LED d’une souris gaming. Windows installe probablement ce type de pilotes optionnels

  • Très beau side project. Je me demande si tu aurais des conseils sur le point de départ ou de bonnes ressources pour quelqu’un qui voudrait essayer quelque chose de similaire

    • C’est à peu près la même chose que ce qu’ont dit les autres. Je recommande de lire https://wiki.osdev.org/Getting_Started et de garder à l’esprit que développer un système d’exploitation prend beaucoup de temps
    • Pour les connaissances pratiques, il y a l’OSDev Wiki ; pour la théorie, il faut regarder du côté des livres sur la conception des systèmes d’exploitation et l’architecture des ordinateurs
    • En Rust, il y a https://os.phil-opp.com/ ; pour le développement de systèmes d’exploitation en général, il y a https://github.com/tuhdo/os01. Et Operating Systems: Three Easy Pieces vaut vraiment le détour

  • Excellent. Je ne m’attendais pas à un tel ensemble de fonctionnalités. Je me demande si tu comptes porter davantage de logiciels à l’avenir

    • Oui, j’ai l’intention d’en porter d’autres. Je ne veux pas mettre de code tiers dans l’OS de base, mais les ports sont un excellent moyen d’exécuter des choses que je n’ai pas encore écrites moi-même
      J’ai encore quelques ports en local qui ne fonctionnent pas. git, binutils, gcc, make compilent tous, mais produisent des erreurs étranges. C’est probablement lié à un bug dans ma libc ou dans les appels système