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 (ordonnancement, allocation de mémoire, etc.) constituent 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é principale est isolée des services système et des pilotes de périphériques (qui ne sont en fait que des services système). Par exemple, les systèmes de fichiers VFS (virtual file system) et block device (i.e. minixfs) sont des processus séparés qui s'exécutent en dehors de l'espace du noyau, utilisant l'IPC pour communiquer avec le noyau, les autres services et les processus utilisateurs. En bref, si c'est un module sous Linux, c'est un service dans un micro-noyau, indiquant un processus isolé.
Ne pas confondre le terme modulaire noyau pour être 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é dans le même espace que celui qui gère la fonctionnalité de base (espace du noyau) et qu'il s'exécute à partir de celui-ci.
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 lance une interruption. Cela peut également être considéré comme un inconvénient, car cela peut cacher des bogues assez critiques (ou les faire paraître moins critiques, car le problème semble se résoudre continuellement). Il est considéré comme un grand avantage dans les scénarios où vous ne pouvez tout simplement pas corriger quelque chose de façon pratique 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 fibrilles sont mises en œuvre. En outre, la recherche d'un problème de FS/écriture implique d'examiner le processus de l'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 n'obtenez rien, il est temps d'examiner le service IPC. Ceci est souvent plus facile dans un noyau monolithique. GNU Hurd souffre de ces problèmes de débogage ( référence ). Je ne parlerai même pas du checkpointing dans le cas de files de messages complexes. Les micro-noyaux ne sont pas faits pour les âmes sensibles.
Le chemin le plus court vers un noyau stable et fonctionnel est l'approche monolithique. L'une ou l'autre de ces approches peut offrir une interface POSIX, où la conception du noyau devient de peu d'intérêt pour quelqu'un qui veut simplement écrire du code à exécuter sur une conception donnée.
J'utilise Linux (monolithique) en production. Cependant, la majeure partie de mon apprentissage, de mon piratage ou de mon bricolage en matière de développement de noyau est consacrée à un micro-noyau, à savoir HelenOS .
Modifier
Si vous êtes arrivé jusqu'ici à travers ma très longue réponse, vous allez probablement vous amuser en lisant l'article " ". Grand débat Torvalds-Tanenbaum sur la conception du noyau '. C'est encore plus drôle à lire en 2013, plus de 20 ans après que cela ait transpiré. La partie la plus drôle était la signature de Linus dans un des derniers messages :
Linus "my first, and hopefully last flamefest" Torvalds
Évidemment, cela ne s'est pas réalisé, pas plus que la prédiction de Tanenbaum selon laquelle les x86 seraient bientôt obsolètes.
NB :
Quand je dis "Minix", je n'implique pas Minix 3. De plus, lorsque je mentionne The HURD, je fais référence (principalement) au micro-noyau Mach. Il n'est pas dans mon intention de dénigrer le travail récent des autres.