Comment le noyau Linux se compare-t-il aux architectures de micro-noyaux?

J'ai lu un jour que l'un des avantages d'une architecture de micro-noyau est que vous pouvez arrêter / démarrer des services essentiels tels que la mise en réseau et les systèmes de fichiers, sans avoir à redémarrer l'ensemble du système. Mais étant donné que le noyau Linux de nos jours (était-ce toujours le cas?) Offre la possibilité d'utiliser des modules pour obtenir le même effet, quels sont les avantages (restants) d'un micro-noyau?

Les micro- noyaux nécessitent moins de code pour être exécutés dans le mode le plus interne et le plus fiable que les noyaux monolithiques . Cela comporte de nombreux aspects, tels que:

• Les micro-noyaux permettent de charger et de décharger à volonté des fonctionnalités non fondamentales (telles que des pilotes pour du matériel non connecté ou non utilisé). Ceci est principalement réalisable sous Linux, via des modules.
• Les micro-noyaux sont plus robustes: si un composant non noyau tombe en panne, il ne prendra pas tout le système avec. Un système de fichiers ou un pilote de périphérique présentant un bogue peut planter un système Linux. Linux n'a pas d'autre moyen d'atténuer ces problèmes que les pratiques de codage et les tests.
• Les micro-noyaux ont une base informatique de confiance plus petite . Ainsi, même un pilote de périphérique ou un système de fichiers malveillant ne peut pas prendre le contrôle de l’ensemble du système (par exemple, un pilote d’origine douteuse pour votre dernier gadget USB ne pourrait pas lire votre disque dur).
• Une conséquence du point précédent est que les utilisateurs ordinaires peuvent charger leurs propres composants qui seraient des composants de noyau dans un noyau monolithique.

Les interfaces graphiques Unix sont fournies via la fenêtre X, qui correspond au code utilisateur (à l'exception du pilote de périphérique vidéo). De nombreux ordinateurs modernes permettent aux utilisateurs ordinaires de charger des pilotes de système de fichiers via FUSE . Une partie du filtrage des paquets sur le réseau Linux peut être effectuée dans les pays utilisateurs. Toutefois, les pilotes de périphérique, les planificateurs, les gestionnaires de mémoire et la plupart des protocoles de réseau ne sont toujours basés que sur le noyau.

Un débat classique (si daté) sur Linux et les micro-noyaux est le débat Tanenbaum – Torvalds . Vingt ans plus tard, on pourrait dire que Linux évolue très lentement vers une structure de micro-noyau (les modules chargeables sont apparus très tôt, FUSE est plus récent), mais il reste encore un long chemin à parcourir.

Une autre chose qui a changé est la pertinence accrue de la virtualisation sur les ordinateurs de bureau et les ordinateurs embarqués haut de gamme: pour certaines raisons, la distinction pertinente n’est pas entre le noyau et l’utilisateur, mais entre l’ OS hyperviseur et les systèmes d’exploitation invités.

Un micro-noyau limite le temps pendant lequel le système est en mode noyau, par opposition à l'espace utilisateur, au minimum absolu.

Si un crash se produit en mode noyau, tout le noyau tombe en panne, ce qui signifie que tout le système tombe en panne. Si un crash se produit en mode utilisateur, seul ce processus est interrompu. Linux est robuste à cet égard, mais il est toujours possible pour tout sous-système du noyau d'écrire sur la mémoire de tout autre sous-système du noyau, à dessein ou accidentellement.

Le concept de micro-noyau met beaucoup de choses qui sont traditionnellement en mode noyau, telles que la mise en réseau et les pilotes de périphériques, dans l'espace utilisateur. Puisque le micro-noyau n’est pas vraiment responsable de beaucoup, cela signifie également qu’il peut être plus simple et plus fiable. Pensez à la façon dont le protocole IP, en étant simple et stupide, conduit réellement à des réseaux robustes en poussant la complexité vers les bords et en laissant le noyau maigre et moyen.

Vous devriez lire l'autre côté du problème:

Extreme High Performance Computing ou Pourquoi les micro-noyaux craignent

Le système de fichiers appartient au noyau

Jetez un coup d’œil à l’architecture x86 - le noyau monolithique n’utilise que les anneaux 0 et 3. Un véritable gâchis. Mais encore une fois, cela peut être plus rapide, en raison de moins de changements de contexte.

1. Le noyau monolithique est beaucoup plus ancien que le microkernel . Il est utilisé dans Unix alors que l’idée du micro-noyau est apparue à la fin des années 80 .

2. Les exemples de systèmes d'exploitation dotés de noyaux monolithiques sont UNIX, LINUX, tandis que les systèmes d'exploitation dotés de micro- noyaux sont QNX, L4, HURD et initialement Mach (non MacOS X), qui a ensuite été converti en noyau hybride. Même MINIX n'est pas un micro-noyau pur, car ses pilotes de périphérique sont compilés dans le noyau.

3. Les noyaux monolithiques sont plus rapides que les micro- noyaux . Le premier micro-noyau de Mach est 50% plus lent que les noyaux monolithiques. Les versions ultérieures telles que L4 ne sont que 2% ou 4% moins rapides que le noyau monolithique .

4. Les noyaux monolithiques sont généralement volumineux, tandis que les micro- noyaux purs doivent être de petite taille , même dans le cache de premier niveau du processeur (micro-noyau de première génération).

5. Dans les noyaux monolithiques, les pilotes de périphérique résident dans l’ espace noyau tandis que dans le micro-noyau, les pilotes de périphérique résident dans l’ espace utilisateur .

6. Étant donné que les pilotes de périphérique résident dans l’espace noyau, le noyau monolithique est moins sécurisé que le microkernel (une défaillance du pilote peut entraîner un crash). Les micro- noyaux sont plus sûrs que les noyaux monolithiques, ils sont donc utilisés dans de nombreux dispositifs militaires.

7. Les noyaux monolithiques utilisent des signaux et des sockets pour assurer l'IPC, tandis que l'approche du micro-noyau utilise des files de messages . Le 1 ^er gen de micronoyau mal mis en œuvre IPC afin qu'ils étaient lents sur les changements de contexte.

8. Ajouter de nouvelles fonctionnalités à un système monolithique signifie recompiler l’ensemble du noyau tout en permettant d’ajouter de nouvelles fonctionnalités ou correctifs sans recompiler.

Windows NT (le noyau sous-jacent aux systèmes Windows actuels) a commencé comme une conception de micro-noyau tout à fait vanille. En raison de problèmes de performances, de plus en plus de code "userland" a migré dans le "micokernel" ... aujourd'hui, sa structure de micro-noyau est restée inchangée.

Le cas est que le noyau Linux est un hybride de monolithique et de microkernel. Dans une implémentation monolithique pure, aucun module ne se charge au moment de l'exécution.

Les termes monolithic kernelet microkernelne peuvent pas être comparés sérieusement car ils décrivent différents aspects de la conception du noyau (structure par rapport à la taille).

Un noyau monolithique typique était le noyau SunOS-4.x et Linux est toujours similaire, car vous configurez manuellement le contenu du noyau de base.

Le noyau Solaris (à partir de 2.1 sur 1992) ne peut plus être appelé monolithique car tous les pilotes sont chargés automatiquement à la demande et seule une infime partie est chargée lors du démarrage initial.

SunOS-4.x, Solaris (SunOS-5.x) et Linux sont tous des implémentations à contexte unique. Tout leur code s'exécute dans un seul contexte MMU.

Mac OS X est basé sur Mach et fonctionne comme une implémentation multi-contextes avec plusieurs processus séparés par des contextes MMU. Dans ce concept, les pilotes sont dans des processus et des contextes MMU distincts.

De nombreuses personnes qualifient Mac OS X de "système à micro-noyau", mais il se peut que le noyau de base ne soit pas plus petit que le noyau de base de Solaris.

Il semble donc qu'il serait préférable de parler single context kernelscontre multi context kernels.