diff --git a/notes/new-os.md b/notes/new-os.md new file mode 100644 index 0000000..5eaec3c --- /dev/null +++ b/notes/new-os.md @@ -0,0 +1,111 @@ +# Idées pour la suite + +Deux pistes : + +* Se contenter de xv6 pour apprendre le dév bas niveau et s'arrêter là. + Éventuellement jouer à faire quelques optimisations, ajouter des syscalls, etc. + Cette option permet d'apprendre sans trop forcer. + +* Contribuer à un projet existant. + +* Tenter de conquérir le monde. + +# Contribution à un projet existant + +Plein de pistes : + +- Ne pas développer tout un OS, mais seulement contribuer à un projet. + Soit de niche : Minix, DuskOS (c'est du Forth), Plan9, Fuchsia ou L4 ? + Soit un poil plus utilisé : un BSD, un OS embarqué type Zephyr, Linux ? + + La question se posera aussi de savoir ce qu'on veut faire avec. + Des pistes : + - Ajouter des parties manquantes dans Minix pour le rendre plus proche des fonctionnalités d'un OS moderne. + Il manque actuellement quelques fonctionnalités assez majeures, comme l'USB entre autres. + - Une sortie audio HDMI ou du bluetooth sur OpenBSD. + - Améliorer la prise en charge du matériel sur Plan9 ou Minix. + - Ajouter pledge et unveil sur Linux. + + QUELLE QUE SOIT NOTRE DÉCISION : améliorer un OS existant est toujours une bonne idée et peut se faire en parallèle d'un autre projet. + +# Conquête du monde (en toute humilité) + +Cette dernière option implique de développer un OS qui n'a encore jamais été fait, pour se lancer un défi. +Exemple : un OS à micro-noyau en Scheme. +Un OS dans lequel on partirait sur l'implémentation de ce qui nous passe par la tête, sans s'embêter avec les standards dont on ne veut pas. + +Intéressant mais bien plus complexe que le reste. +On en apprendra beaucoup tout en ayant un OS qui pourrait intéresser des gens. + +Concernant les fonctionnalités qui m'intéressent bien : + +- Avoir un OS qu'on peut améliorer à la volée via un interpréteur Scheme côté noyau. + (ou du Forth, sans doute avec DuskOS car c'est déjà là et activement développé) + +- Une architecture à micro-noyaux qui permette : + + - L'écriture de pilotes en mode utilisateur. + Ça se fait déjà sur certains systèmes, donc ce n'est pas insurmontable. + + - La mise à jour en live du système, sans redémarrage. + Comme avec Minix par exemple, sauf que si on a un REPL à base de Scheme en espace noyau… le niveau de gloire augmente. + +- Un développement unifié de tout le système façon BSD, + contrairement au développement chaotique côté Linux où tous les programmes sont écrits différemment. + +- Reprendre masse de concepts de Plan9. + Selon moi Plan9 est le système le plus intéressant conceptuellement et devrait être étudié, quoi qu'on décide. + +- Reprendre quelques concepts de DuskOS. + DuskOS implémente HAL, une couche d'abstration pour générer des instructions binaires. + Cette abstraction fournit une API pour que des compilateurs puissent s'y greffer et ne pas eux-même gérer la dernière étape de compilation. + Le développeur principal a fait un compilateur C et Scheme avec cette abstraction. + Cette factorisation de la dernière étape des compilateurs rend le code plus concis. + +- Une couche de compatibilité avec BSD (voire Linux) pour porter des outils et en faire beaucoup plus rapidement un système utilisable « pour de vrai ». + +Il faut reprendre les bonnes idées. +Il faut lire le code des systèmes actuels pour apprendre et s'inspirer. + +# Liens qui pourraient s'avérer importants pour la suite + +- Running Scheme On Bare Metal (Experience Report): + https://doc.lagout.org/programmation/Lisp/Scheme/An%20Introduction%20to%20Scheme%20and%20its%20Implementation.pdf + +- un papier qui indique comment faire des micro-noyaux rapides + (l'idée générale est de limiter au maximum les changements de contexte, ce qui semble se faire sans trop de mal sur du x86) + https://ipads.se.sjtu.edu.cn/_media/publications/skybridge-eurosys19.pdf + +- introduction à x86 par les gens qui font ffmpeg + https://github.com/FFmpeg/asm-lessons + +# NOTES EN VRAC SUR FUCHSIA + +Le noyau Zircon (de Fuchsia, OS de Google), en quelques mots : + +- Reprend quelques concepts de Plan9, par exemple le fait qu'un processus enfant n'a pas accès à tout par défaut, seulement à ce que le parent lui donne. + Un processus est nommé « composant » dans la terminologie de Fuchsia, car le concept s'éloigne un peu de celui de processus. + Un processus dans le monde d'Unix est fortement corrélé à l'utilisateur qui le lance, et l'utilisateur est le centre de l'attention en ce qui concerne la sécurité. + Si un utilisateur a les droits sur un répertoire, la totalité des processus qu'il lance peuvent accéder au contenu du répertoire. + Dans Fuchsia, les processus ont eux-mêmes des droits particuliers (« capabilities ») et reçoivent un sous-ensemble des droits de l'utilisateur. + + NOTE : à mon faible niveau de connaissances sur Plan9, ça ressemble quand même fortement à ce que fait Google dans Fuchsia. + Plan9 ne se complexifie pas la vie autant que Fuchsia puisque pour Plan9 tout est fichier. + Plan9 conserve donc la palme de l'OS le plus simple (et de très loin). + +- Tout n'est pas « fichiers » mais plutôt « handles » c-à-d un objet qui représente ce qu'on peut faire avec. + En gros, ça va plus loin que simplement ouvrir/fermer/lire/écrire. + D'un point de vue de l'utilisateur, c'est bien entendu une petite complexité supplémentaire. + +- Utilise un mécanisme d'IPC où tous les messages ont une signature précise. + On définit finement la structure des messages que les processus s'échangent. + Le langage pour décrire ces messages IPC s'appelle FIDL. + Cela remplace une partie des appels système assez classiques qu'on connaît sous Unix par des échanges de messages structurés (par de simples tableaux d'octets). + +- Vidéo youtube qui présente certains aspects de Fuchsia : + "An IPC Language For The Whole Operating System" by Ian McKellar (Strange Loop 2022) + https://www.youtube.com/watch?v=ApHpmA1k73k + + NOTE : dans les commentaires, un gars qui a visiblement bossé sur L4 dit qu'il est content que finalement quelqu'un ait regardé la doc de L4. + L4 qui, je suppose, implique également des capabilities, handles, FIDL, etc. + En gros, Fuchsia n'a rien inventé.