Voila, j'ai évolué un peu dans mes projets. Je suis pas pressé et avec mes troubles neurologiques j'ai des problèmes d'attention, de concentration et mémorisation. Je dois donc être patient.
Heureusement que chatGPT et Deepseek va m'aider dans mon entreprise. Cela compense mon handicap. On va donc dans le cadre de mon entreprise Kor51, faire du Kernel Engineering. On va pas s'attaquer à Linux... Je suis contre car ils m'énervent dans deux points:
- Le nombre de couche et appels systèmes: c'est des spagettis et totalement indigeste
- Le nombre de ligne: + 22 millions et jusqu'à 1 millions rien que pour le kernel. Autrement dit cela refroidis les débutants comme moi, trop complexe à explorer, on ce demande par ou commencer? C'est trop gros. Un projet à échelle humaine en solo c'est 1500 pages A4 de code soit 82 000 lignes. Au délà c'est impossible à réellement maintenir du code.
Donc je suis contre de complexifier les choses.... Il faut simplifier les choses. On va donc étudier les microkernel qui font pas plus de 5000 lignes de code, et donc de la modularité... Linux c'est une usine à gaz. 100mo rien que le kernel, c'est considérable, en quelques années cela a exploser sa taille. Et c'est son défaut. Je pense même que Linux est fini sur du long terme car pas maintenable, trop peu de candidat en réalité, mais c'est un autre débat. Je vois par exemple RedoxOS utilise un microkernel en Rust. C'est bien plus malin.
On va donc développer un microkernel innovant hybride C/C++. J'ai défini des exigences d'architecture avec chatGPT pour limiter les defauts d'UNIX. C'est mon métier l'ingénierie système et le point de vue de l'architecte. Je suis plus négligeant sur le code et l'implémentation.
Objectif philosophique
- Minimalisme extrême : Réduire la taille du noyau pour limiter la complexité. principe KISS
- Haute performance : Réduire le nombre de transitions noyau/espace utilisateur.
- Modularité : Faciliter les mises à jour et l’extensibilité.
- Séparation stricte des privilèges : Protéger l’intégrité du noyau.
- Pas nécessairement UNIX : Explorer d’autres paradigmes OS (ex: message-passing, objets, etc.).
ANALYSE DES PROBLEMES KERNELS UNIX
1.1. Poids et Complexité
Unix suit la philosophie "tout est fichier", mais :
- Trop de couches logicielles → Chaque appel système traverse plusieurs couches (VFS, drivers, libc).
- Système de fichiers omniprésent → Beaucoup de kernels modernes imposent un VFS dès le départ, même pour des tâches simples.
Solution : Supprimer le paradigme UNIX et repenser le modèle d’accès aux ressources (mémoire directe, objets, IPC optimisé).
1.2. Processus et Scheduling Inefficaces
- Unix utilise des processus lourds, avec une séparation stricte entre user/kernel space.
- Syscalls trop fréquents → Chaque syscall est un changement de contexte coûteux.
- Processus lourds → Même un simple fork() duplique trop d’informations.
- Overhead dans les files d’attente du scheduler → Les algorithmes de scheduling classiques (CFS sous Linux) sont optimisés pour du multitâche généraliste, mais coûtent cher en latence.
Solution :
- Remplacer les processus par des threads légers (ou fibres) et limiter les context switches.
- Scheduling basé sur l’événementiel plutôt que sur des files d’attente FIFO.
1.3. IPC Trop Verbeux
- Les microkernels type Mach ou L4 montrent que l’IPC UNIX est trop coûteux.
- Trop de copies mémoire (ex: pipes, sockets, message queues).
- Énorme overhead sur select() et poll() (gaspillage CPU).
Solution :
- Utiliser du shared memory direct entre processus.
- Remplacer select() et poll() par un modèle event-driven rapide (ex: signaux hardware).
1.4. Modèle de Sécurité Obsolète
- Unix repose sur UID/GID et ACLs, mais :
- Trop granulaire → Gérer les permissions sur chaque fichier/processus est lourd.
- Système de droits statique → Pas adapté aux environnements dynamiques (cloud, containers).
Solution :
- Passer à un modèle capability-based (chaque programme possède des jetons de permissions au lieu d’UIDs).
- Inspiré de seL4 et des OS en mode sandbox.
Propositions pour une Nouvelle Architecture
2.1. Supprimer le Système de Fichiers Traditionnel
-
Remplacer "tout est fichier" par "tout est objet"
-
Au lieu d’un VFS lourd, chaque ressource (mémoire, périphériques) est un objet adressable.
- Accès via un système de messages rapides ou mémoire partagée.
Avantage : Pas besoin de filesystem pour démarrer une tâche → accès plus rapide.
2.2. Remplacer les Processus par des "Fibres" Ultra-Légères
-
Éviter les syscalls inutiles
-
Un thread/fibre s’exécute sans passer par le noyau autant que possible.
- Pas de contexte lourd → tout se fait en mémoire partagée entre tâches.
Avantage : Moins de changements de contexte, plus rapide qu’Unix.
2.3. Optimiser l’IPC avec du Partage Mémoire Direct
-
Plus de messages coûteux entre processus
-
Chaque service communique en lisant directement en mémoire partagée.
- Inspiré des architectures type L4, où tout est un échange de mémoire.
Avantage : Pas de copies mémoire inutiles, latence minimale
2.4. Scheduling et Interruption Repensés
-
Éviter les interruptions fréquentes
-
Scheduling event-driven : pas de polling, pas d’horloge système tournant en boucle.
- Priorité aux tâches critiques avec un scheduler ultra-réactif (ex: RTOS).
Avantage : Moins de CPU utilisé, réactivité accrue.
Un kernel UNIX est trop lourd, trop généraliste. On peut optimiser :
- Supprimer le paradigme "tout est fichier".
- Éliminer le modèle UNIX de gestion des processus.
- Optimiser IPC via mémoire partagée.
- Refondre le scheduling pour qu’il soit ultra-rapide.
prototype
Le premier prototype du kernel doit faire 1000 lignes de code. Je travail dessus en ce moment, mais avant je dois mettre à jour mes compétences en C/C++. Je réapprends les bases de la programmation et je commence à explorer la construction d'OS.
Vous trouverez les premiers développant du Kernel nommé "DaoGoi" qui veut dire "super étrange" en Narkanta. J'ai commencé à l'écrire sur le repo: https://codeberg.org/legoffant/daogoi
Je cherche des développeurs sur le projet, et est ouvert à toute évolution pour former une équipe de kernel engineering. Vous avez la liste des premieres exigences sur le kernel à implémenter.
On peut également s'inspirer de cette article: OS in 1000 lines qui a étudié l'implémentation de microkernel minimaliste.