A few more ideas.

notes/next-move.md

@@ -1,14 +1,15 @@
-# Idées pour la suite
+Que pourrions-nous faire de nos dix doigts ?
+Une fois qu'on voudra se lancer dans du code, après avoir lu le livre (en entier ou pas) ou vu les vidéos, quelles sont nos possibilités ?
 
-Au choix :
+# Idées pour la suite
 
 1. 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.
 
-2. Contribuer à un projet existant.
+2. Contribuer à un projet existant, utilisé au-delà de l'aspect pédagogique.
    Cette option peut être complémentaire à une autre.
-   C'est l'option qui est la plus sociale, notre travail est directement utile pour plein de gens.
+   C'est l'option qui est la plus sociale, notre travail est directement utile à d'autres.
 
    L'étude de ces systèmes est intéressante peu importe ce qu'on décide de faire par ailleurs.
    On plonge occasionnellement dans leur code et on apprend.
@@ -29,9 +30,11 @@ Que faire avec ces systèmes ? Des pistes :
   Exemple : pas de multicœur, USB incomplet (de mémoire), etc.
 
 - Sur OpenBSD :
+
   - Une sortie audio HDMI.
   - Du bluetooth.
   - Un système de fichiers avec un journal (type HAMMER2).
+    Si j'en crois des gens sur reddit, c'est un gros travail à cause du VFS qui est un peu simpliste pour un FS sophistiqué.
 
 - Plan9 et Minix : améliorer la prise en charge du matériel.
 
@@ -42,14 +45,11 @@ Que faire avec ces systèmes ? Des pistes :
 Cette dernière option implique de développer un OS qui n'a encore jamais été fait, pour se lancer un défi.
 Ma proposition serait de faire un OS à micro-noyau en Scheme.
 
-Intéressant mais bien plus complexe que le reste.
+Intéressant, divertissant et on obtient instantanément une aura de fou, mais le projet est 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 :
 
-- Un interpréteur Scheme côté noyau pour améliorer le système en direct, à la volée.
-  (Ou du Forth, sans doute avec DuskOS car c'est déjà là et activement développé.)
-
 - Une architecture à micro-noyau qui permette :
 
   - L'écriture de pilotes en mode utilisateur.
@@ -73,6 +73,46 @@ Concernant les fonctionnalités qui m'intéressent bien :
 
 - 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 ».
 
+- Avoir le code noyau en Scheme.
+  (Ou du Forth, sans doute avec DuskOS car c'est déjà là et activement développé.)
+
+  (Le Scheme peut arriver après une première implémentation en C.)
+
+  Le Scheme est très intéressant de par sa simplicité (S-expressions) et son extensibilité (macros).
+  Le langage peut évoluer en DSL pour au final se débarasser entièrement de tout autre langage dans les sources.
+
+  Prenons un exemple.
+  Il est possible d'écrire un programme qui génère du C ou de l'assembleur.
+  /!\ Je ne parle pas de compiler un programme, mais d'écrire un programme qui écrit du C ou de l'assembleur.
+  Un exemple proche de ce dont je parle est LCC, une sorte de Lisp pour écrire du C :
+    https://github.com/saman-pasha/LCC
+  Notre version pourrait écrire soit du C pour profiter des optimisations des compilateurs C, soit de l'assembleur pour éviter toute dépendance au C.
+  Les macros Scheme permettraient de créer un DSL pour générer à la fois du C et des instructions au linker, par exemple.
+
+  Avantages :
+
+  - Code plus simple qu'en C (ou assembleur).
+    Certains pièges du C sont évités.
+    Pas besoin de jouer avec le préprocesseur C et sa syntaxe inélégante.
+
+  - Le code noyau profite entièrement de l'environnement du langage hôte.
+    On pourrait ajouter des vérifications de type si on le souhaite.
+
+  - Performances optimales, le code noyau en Scheme n'est qu'une surcouche à l'assembleur.
+    Le noyau ne continent que le code dont il a besoin.
+
+  - Ce principe pourrait être réutilisé dans du code beaucoup plus complexe, comme les pilotes des périphériques.
+
+  Un interpréteur pourra éventuellement être implémenté dans un second temps.
+  L'idée serait d'améliorer le système en direct pendant qu'il tourne.
+
+  - L'interpréteur sera également un compilateur pour être performant.
+    L'implémentation peut fortement s'inspirer de Forth pour ajouter de nouvelles fonctions à la volée.
+
+  - Cet interpréteur n'implémentera que ce qui est nécessaire pour un noyau, inutile de dégainer R7RS.
+    Un noyau n'a pas besoin d'optimisations poussées.
+    De même, le ramasse-miettes peut être simpliste, un micro-noyau effectue peu d'actions.
+
 Il faut reprendre les bonnes idées.
 Il faut lire le code des systèmes actuels pour apprendre et s'inspirer.