Un noyau monolithique est un noyau où tous les services (système de fichiers, VFS, pilotes de périphériques, etc.) ainsi que les fonctionnalités de base (planification, allocation de mémoire, etc.) sont un groupe soudé partageant le même espace. Cela s'oppose directement à un micro - noyau .
Un micro-noyau préfère une approche où la fonctionnalité de base est isolée des services système et des pilotes de périphérique (qui sont essentiellement des services système). Par exemple, VFS (système de fichiers virtuel) et les systèmes de fichiers de périphérique de bloc (c'est-à-dire minixfs) sont des processus distincts qui s'exécutent en dehors de l'espace du noyau, utilisant IPC pour communiquer avec le noyau, d'autres services et processus utilisateur. En bref, s'il s'agit d'un module sous Linux, c'est un service dans un micro-noyau, indiquant un processus isolé.
Ne confondez pas le terme noyau modulaire avec tout sauf monolithique. Certains noyaux monolithiques peuvent être compilés pour être modulaires (par exemple Linux), ce qui importe, c'est que le module soit inséré et s'exécute à partir du même espace qui gère les fonctionnalités de base (espace du noyau).
L'avantage d'un micro-noyau est que tout service défaillant peut être facilement redémarré, par exemple, il n'y a pas d'arrêt du noyau si le système de fichiers racine abandonne. Cela peut également être considéré comme un inconvénient, car il peut masquer des bugs assez critiques (ou les faire paraître moins critiques, car le problème semble se résoudre en permanence). Cela est considéré comme un grand avantage dans les scénarios où vous ne pouvez tout simplement pas réparer facilement quelque chose une fois qu'il a été déployé.
L'inconvénient d'un micro-noyau est que la messagerie IPC asynchrone peut devenir très difficile à déboguer, surtout si des fibrilles sont implémentées. De plus, le simple fait de rechercher un problème FS / écriture signifie examiner le processus d'espace utilisateur, le service de périphérique de bloc, le service VFS, le service de système de fichiers et (éventuellement) le service PCI. Si vous obtenez un blanc à ce sujet, il est temps de regarder le service IPC. C'est souvent plus facile dans un noyau monolithique. GNU Hurd souffre de ces problèmes de débogage ( référence ). Je ne vais même pas entrer dans les points de contrôle lorsque je traite des files d'attente de messages complexes. Les micro-noyaux ne sont pas pour les faibles de cœur.
Le chemin le plus court vers un noyau stable et fonctionnel est l'approche monolithique. L'une ou l'autre approche peut offrir une interface POSIX, où la conception du noyau devient peu intéressante pour quelqu'un qui veut simplement écrire du code pour s'exécuter sur n'importe quelle conception donnée.
J'utilise Linux (monolithique) en production. Cependant, la majeure partie de mon apprentissage, du piratage ou du bricolage avec le développement du noyau va dans un micro-noyau, en particulier HelenOS .
Éditer
Si vous êtes allé aussi loin dans ma réponse très longue, vous aurez probablement du plaisir à lire le « Grand débat Torvalds-Tanenbaum sur la conception du noyau ». C'est encore plus drôle de lire en 2013, plus de 20 ans après qu'il soit apparu. La partie la plus drôle était la signature de Linus dans l'un des derniers messages:
Linus "my first, and hopefully last flamefest" Torvalds
De toute évidence, cela ne s'est pas réalisé plus que la prédiction de Tanenbaum selon laquelle x86 serait bientôt obsolète.
NB:
Quand je dis "Minix", je n'implique pas Minix 3. De plus, quand je mentionne The HURD, je fais référence (principalement) au micro-noyau Mach. Je n'ai pas l'intention de dénigrer le travail récent des autres.