Noyau (système d'exploitation)

Le noyau est un programme informatique au cœur du système d'exploitation d' un ordinateur et a généralement un contrôle complet sur tout ce qui se trouve dans le système. Le noyau est également responsable de la prévention et de l'atténuation des conflits entre les différents processus. C'est la partie du code du système d'exploitation qui réside toujours en mémoire et facilite les interactions entre les composants matériels et logiciels. Un noyau complet contrôle toutes les ressources matérielles (par exemple, les E/S, la mémoire, la cryptographie) via les pilotes de périphériques , arbitre les conflits entre les processus concernant ces ressources et optimise l'utilisation des ressources communes, par exemple l'utilisation du processeur et du cache , les systèmes de fichiers et les sockets réseau. Sur la plupart des systèmes, le noyau est l'un des premiers programmes chargés au démarrage (après le chargeur de démarrage ). Il gère le reste du démarrage ainsi que la mémoire, les périphériques et les demandes d'entrée/sortie (E/S) du logiciel , les traduisant en instructions de traitement de données pour l' unité centrale de traitement .

Le code critique du noyau est généralement chargé dans une zone séparée de la mémoire, qui est protégée de l'accès par les logiciels d'application ou d'autres parties moins critiques du système d'exploitation. Le noyau effectue ses tâches, telles que l'exécution des processus, la gestion des périphériques matériels tels que le disque dur et la gestion des interruptions, dans cet espace noyau protégé . En revanche, les programmes d'application tels que les navigateurs, les traitements de texte ou les lecteurs audio ou vidéo utilisent une zone séparée de la mémoire, l'espace utilisateur . Cette séparation empêche les données utilisateur et les données du noyau d'interférer les unes avec les autres et de provoquer une instabilité et une lenteur, ainsi que d'empêcher les applications défectueuses d'affecter d'autres applications ou de faire planter l'ensemble du système d'exploitation. Même dans les systèmes où le noyau est inclus dans les espaces d'adressage des applications , la protection de la mémoire est utilisée pour empêcher les applications non autorisées de modifier le noyau.

L' interface du noyau est une couche d'abstraction de bas niveau . Lorsqu'un processus demande un service au noyau, il doit invoquer un appel système , généralement via une fonction wrapper .

Il existe différentes conceptions d'architecture de noyau. Les noyaux monolithiques s'exécutent entièrement dans un espace d'adressage unique avec le processeur exécuté en mode superviseur , principalement pour des raisons de vitesse. Les micro-noyaux exécutent la plupart de leurs services, mais pas tous, dans l'espace utilisateur, comme le font les processus utilisateur, principalement pour des raisons de résilience et de modularité . MINIX 3 est un exemple notable de conception de micro-noyau. Le noyau Linux est à la fois monolithique et modulaire, car il peut insérer et supprimer des modules de noyau chargeables au moment de l'exécution.

Ce composant central d'un système informatique est responsable de l'exécution des programmes. Le noyau se charge de décider à tout moment lequel des nombreux programmes en cours d'exécution doit être attribué au(x) processeur(s).

La mémoire vive (RAM) est utilisée pour stocker à la fois les instructions et les données d'un programme. En général, les deux doivent être présentes en mémoire pour qu'un programme puisse s'exécuter. Souvent, plusieurs programmes souhaitent accéder à la mémoire, ce qui demande souvent plus de mémoire que ce dont dispose l'ordinateur. Le noyau est chargé de décider quelle mémoire chaque processus peut utiliser et de déterminer ce qu'il faut faire lorsque la mémoire disponible est insuffisante.

Les périphériques d'E/S incluent, sans s'y limiter, des périphériques tels que des claviers, des souris, des lecteurs de disque, des imprimantes, des périphériques USB , des adaptateurs réseau et des périphériques d'affichage . Le noyau fournit des méthodes pratiques pour que les applications puissent utiliser ces périphériques, qui sont généralement abstraits par le noyau, de sorte que les applications n'ont pas besoin de connaître leurs détails d'implémentation.

Les aspects clés nécessaires à la gestion des ressources sont la définition du domaine d'exécution ( espace d'adressage ) et le mécanisme de protection utilisé pour gérer l'accès aux ressources au sein d'un domaine. Les noyaux fournissent également des méthodes de synchronisation et de communication interprocessus (IPC). Ces implémentations peuvent être situées dans le noyau lui-même ou le noyau peut également s'appuyer sur d'autres processus qu'il exécute. Bien que le noyau doive fournir l'IPC afin de permettre l'accès aux fonctionnalités fournies par les autres, les noyaux doivent également fournir aux programmes en cours d'exécution une méthode pour effectuer des demandes d'accès à ces fonctionnalités. Le noyau est également responsable du changement de contexte entre les processus ou les threads.

Le noyau a un accès complet à la mémoire du système et doit permettre aux processus d'accéder en toute sécurité à cette mémoire lorsqu'ils en ont besoin. Souvent, la première étape pour y parvenir est l'adressage virtuel , généralement réalisé par pagination et/ou segmentation . L'adressage virtuel permet au noyau de faire apparaître une adresse physique donnée comme une autre adresse, l'adresse virtuelle. Les espaces d'adressage virtuel peuvent être différents pour différents processus ; la mémoire à laquelle un processus accède à une adresse (virtuelle) particulière peut être une mémoire différente de celle à laquelle un autre processus accède à la même adresse. Cela permet à chaque programme de se comporter comme s'il était le seul (à part le noyau) à s'exécuter et empêche ainsi les applications de se planter les unes les autres.

Sur de nombreux systèmes, l'adresse virtuelle d'un programme peut faire référence à des données qui ne sont pas actuellement en mémoire. La couche d'indirection fournie par l'adressage virtuel permet au système d'exploitation d'utiliser d'autres magasins de données, comme un disque dur , pour stocker ce qui devrait autrement rester dans la mémoire principale ( RAM ). En conséquence, les systèmes d'exploitation peuvent autoriser les programmes à utiliser plus de mémoire que ce dont le système dispose physiquement. Lorsqu'un programme a besoin de données qui ne sont pas actuellement en RAM, le processeur signale au noyau que cela s'est produit, et le noyau répond en écrivant le contenu d'un bloc de mémoire inactif sur le disque (si nécessaire) et en le remplaçant par les données demandées par le programme. Le programme peut alors reprendre à partir du point où il a été arrêté. Ce schéma est généralement connu sous le nom de pagination à la demande .

L'adressage virtuel permet également la création de partitions virtuelles de mémoire en deux zones disjointes, l'une étant réservée au noyau ( espace noyau ) et l'autre aux applications ( espace utilisateur ). Les applications ne sont pas autorisées par le processeur à adresser la mémoire du noyau, ce qui empêche une application d'endommager le noyau en cours d'exécution. Cette partition fondamentale de l'espace mémoire a beaucoup contribué aux conceptions actuelles des noyaux à usage général et est presque universelle dans de tels systèmes, bien que certains noyaux de recherche (par exemple, Singularity ) adoptent d'autres approches.

Pour exécuter des fonctions utiles, les processus doivent accéder aux périphériques connectés à l'ordinateur, qui sont contrôlés par le noyau via des pilotes de périphériques . Un pilote de périphérique est un programme informatique encapsulant, surveillant et contrôlant un périphérique matériel (via son interface matérielle/logicielle (HSI)) pour le compte du système d'exploitation. Il fournit au système d'exploitation une API, des procédures et des informations sur la manière de contrôler et de communiquer avec un certain élément matériel. Les pilotes de périphériques sont une dépendance importante et vitale pour tous les systèmes d'exploitation et leurs applications. L'objectif de conception d'un pilote est l'abstraction ; la fonction du pilote est de traduire les appels de fonction abstraits imposés par le système d'exploitation (appels de programmation) en appels spécifiques au périphérique. En théorie, un périphérique devrait fonctionner correctement avec un pilote approprié. Les pilotes de périphériques sont utilisés par exemple pour les cartes vidéo, les cartes son, les imprimantes, les scanners, les modems et les cartes réseau.

Au niveau matériel, les abstractions courantes des pilotes de périphériques incluent :

• Interfaçage direct
• Utilisation d'une interface de haut niveau ( BIOS vidéo )
• Utilisation d'un pilote de périphérique de niveau inférieur (pilotes de fichiers utilisant des pilotes de disque)
• Simuler le travail avec du matériel, tout en faisant quelque chose de complètement différent

Et au niveau logiciel, les abstractions des pilotes de périphériques incluent :

• Permettre au système d'exploitation d'accéder directement aux ressources matérielles
• Implémentation uniquement des primitives
• Implémentation d'une interface pour les logiciels non pilotes tels que TWAIN
• Implémentation d'un langage (souvent un langage de haut niveau tel que PostScript )

Par exemple, pour montrer quelque chose à l'utilisateur sur l'écran, une application ferait une requête au noyau, qui transmettrait la requête à son pilote d'affichage, qui serait alors chargé de tracer le caractère/pixel.

Un noyau doit maintenir une liste des périphériques disponibles. Cette liste peut être connue à l'avance (par exemple, sur un système embarqué où le noyau sera réécrit si le matériel disponible change), configurée par l'utilisateur (typique sur les anciens PC et sur les systèmes qui ne sont pas conçus pour un usage personnel) ou détectée par le système d'exploitation au moment de l'exécution (normalement appelé plug and play ). Dans les systèmes plug-and-play, un gestionnaire de périphériques effectue d'abord une analyse sur différents bus périphériques , tels que Peripheral Component Interconnect (PCI) ou Universal Serial Bus (USB), pour détecter les périphériques installés, puis recherche les pilotes appropriés.

La gestion des périphériques étant un sujet très spécifique au système d'exploitation , ces pilotes sont gérés différemment par chaque type de conception de noyau, mais dans tous les cas, le noyau doit fournir les E/S pour permettre aux pilotes d'accéder physiquement à leurs périphériques via un port ou un emplacement mémoire. Des décisions importantes doivent être prises lors de la conception du système de gestion des périphériques, car dans certaines conceptions, les accès peuvent impliquer des changements de contexte , ce qui rend l'opération très gourmande en ressources CPU et entraîne facilement une surcharge de performances significative.

En informatique, un appel système est la manière dont un processus demande un service au noyau d'un système d'exploitation qu'il n'a normalement pas l'autorisation d'exécuter. Les appels système fournissent l'interface entre un processus et le système d'exploitation. La plupart des opérations interagissant avec le système nécessitent des autorisations qui ne sont pas disponibles pour un processus de niveau utilisateur, par exemple, les E/S effectuées avec un périphérique présent sur le système, ou toute forme de communication avec d'autres processus nécessitent l'utilisation d'appels système.

Un appel système est un mécanisme utilisé par le programme d'application pour demander un service au système d'exploitation. Il utilise une instruction en code machine qui provoque le changement de mode du processeur. Par exemple, il peut s'agir du passage du mode superviseur au mode protégé. C'est là que le système d'exploitation effectue des actions telles que l'accès aux périphériques matériels ou à l' unité de gestion de la mémoire . En général, le système d'exploitation fournit une bibliothèque qui se situe entre le système d'exploitation et les programmes utilisateur normaux. Il s'agit généralement d'une bibliothèque C telle que Glibc ou Windows API. La bibliothèque gère les détails de bas niveau de la transmission d'informations au noyau et du passage en mode superviseur. Les appels système incluent close, open, read, wait et write.

Pour effectuer un travail réellement utile, un processus doit pouvoir accéder aux services fournis par le noyau. Cela est implémenté différemment par chaque noyau, mais la plupart fournissent une bibliothèque C ou une API , qui à son tour invoque les fonctions du noyau associées.

La méthode d'appel de la fonction du noyau varie d'un noyau à l'autre. Si l'isolation de la mémoire est utilisée, il est impossible pour un processus utilisateur d'appeler directement le noyau, car cela constituerait une violation des règles de contrôle d'accès du processeur. Voici quelques possibilités :

• Utilisation d'une interruption simulée par logiciel . Cette méthode est disponible sur la plupart des matériels et est donc très courante.
• Utilisation d'une porte d'appel . Une porte d'appel est une adresse spéciale stockée par le noyau dans une liste de la mémoire du noyau à un emplacement connu du processeur. Lorsque le processeur détecte un appel à cette adresse, il redirige à la place vers l'emplacement cible sans provoquer de violation d'accès. Cela nécessite un support matériel, mais le matériel nécessaire est assez courant.
• Utilisation d'une instruction d'appel système spéciale . Cette technique nécessite un support matériel spécial, dont les architectures courantes (notamment x86 ) peuvent manquer. Des instructions d'appel système ont cependant été ajoutées aux modèles récents de processeurs x86, et certains systèmes d'exploitation pour PC les utilisent lorsqu'elles sont disponibles.
• Utilisation d'une file d'attente basée sur la mémoire. Une application qui effectue un grand nombre de requêtes mais n'a pas besoin d'attendre le résultat de chacune d'elles peut ajouter les détails des requêtes à une zone de mémoire que le noyau analyse périodiquement pour rechercher des requêtes.

Un élément important à prendre en compte lors de la conception d'un noyau est la prise en charge qu'il fournit pour la protection contre les pannes ( tolérance aux pannes ) et contre les comportements malveillants ( sécurité ). Ces deux aspects ne sont généralement pas clairement différenciés, et l' adoption de cette distinction dans la conception du noyau conduit au rejet d'une structure hiérarchique pour la protection .

Les mécanismes ou politiques fournis par le noyau peuvent être classés selon plusieurs critères, notamment : statiques (appliqués au moment de la compilation ) ou dynamiques (appliqués au moment de l'exécution ) ; préemptifs ou post-détection ; selon les principes de protection qu'ils satisfont (par exemple, Denning ) ; s'ils sont pris en charge par le matériel ou basés sur le langage ; s'ils constituent davantage un mécanisme ouvert ou une politique contraignante ; et bien d'autres encore.

La prise en charge des domaines de protection hiérarchiques est généralement implémentée à l'aide de modes CPU .

De nombreux noyaux fournissent une implémentation de « capacités », c'est-à-dire des objets fournis au code utilisateur qui permettent un accès limité à un objet sous-jacent géré par le noyau. Un exemple courant est la gestion de fichiers : un fichier est une représentation d'informations stockées sur un périphérique de stockage permanent. Le noyau peut être capable d'effectuer de nombreuses opérations différentes, notamment la lecture, l'écriture, la suppression ou l'exécution, mais une application de niveau utilisateur peut n'être autorisée à effectuer que certaines de ces opérations (par exemple, elle peut n'être autorisée qu'à lire le fichier). Une implémentation courante de ceci consiste pour le noyau à fournir un objet à l'application (généralement appelé « handle de fichier ») sur lequel l'application peut ensuite invoquer des opérations, dont la validité est vérifiée par le noyau au moment où l'opération est demandée. Un tel système peut être étendu pour couvrir tous les objets gérés par le noyau, et même les objets fournis par d'autres applications utilisateur.

Une manière efficace et simple de fournir un support matériel des capacités est de déléguer à l' unité de gestion de la mémoire (MMU) la responsabilité de vérifier les droits d'accès pour chaque accès à la mémoire, un mécanisme appelé adressage basé sur les capacités . La plupart des architectures informatiques commerciales ne disposent pas d'un tel support MMU pour les capacités.

Une approche alternative consiste à simuler des capacités à l'aide de domaines hiérarchiques généralement pris en charge. Dans cette approche, chaque objet protégé doit résider dans un espace d'adressage auquel l'application n'a pas accès ; le noyau conserve également une liste de capacités dans cette mémoire. Lorsqu'une application doit accéder à un objet protégé par une capacité, elle effectue un appel système et le noyau vérifie ensuite si la capacité de l'application lui accorde la permission d'effectuer l'action demandée, et si elle est autorisée, effectue l'accès pour elle (soit directement, soit en déléguant la demande à un autre processus de niveau utilisateur). Le coût en termes de performances du changement d'espace d'adressage limite la praticabilité de cette approche dans les systèmes avec des interactions complexes entre les objets, mais elle est utilisée dans les systèmes d'exploitation actuels pour les objets qui ne sont pas consultés fréquemment ou qui ne sont pas censés s'exécuter rapidement.

Si le micrologiciel ne prend pas en charge les mécanismes de protection, il est possible de simuler une protection à un niveau supérieur, par exemple en simulant des capacités en manipulant des tables de pages , mais cela a des conséquences sur les performances. Le manque de prise en charge matérielle peut toutefois ne pas être un problème pour les systèmes qui choisissent d'utiliser une protection basée sur la langue.

Une décision importante lors de la conception du noyau est le choix des niveaux d'abstraction où les mécanismes et les politiques de sécurité doivent être mis en œuvre. Les mécanismes de sécurité du noyau jouent un rôle essentiel dans la prise en charge de la sécurité à des niveaux plus élevés.

Une approche consiste à utiliser le support du microprogramme et du noyau pour la tolérance aux pannes (voir ci-dessus) et à élaborer la politique de sécurité pour les comportements malveillants par-dessus (en ajoutant des fonctionnalités telles que des mécanismes de cryptographie si nécessaire), en déléguant une partie de la responsabilité au compilateur . Les approches qui délèguent l'application de la politique de sécurité au compilateur et/ou au niveau de l'application sont souvent appelées sécurité basée sur le langage .

L'absence de nombreux mécanismes de sécurité critiques dans les systèmes d'exploitation courants actuels empêche la mise en œuvre de politiques de sécurité adéquates au niveau de l'abstraction des applications . En fait, une idée fausse courante en matière de sécurité informatique est que n'importe quelle politique de sécurité peut être mise en œuvre dans une application, indépendamment de la prise en charge du noyau.

Selon les développeurs de Mars Research Group, le manque d'isolation est l'un des principaux facteurs qui compromettent la sécurité du noyau. Ils proposent leur cadre d'isolation des pilotes pour la protection, principalement dans le noyau Linux.

Les systèmes informatiques classiques utilisent aujourd'hui des règles imposées par le matériel pour déterminer quels programmes sont autorisés à accéder à quelles données. Le processeur surveille l'exécution et arrête un programme qui viole une règle, comme un processus utilisateur qui tente d'écrire dans la mémoire du noyau. Dans les systèmes qui ne prennent pas en charge les fonctionnalités, les processus sont isolés les uns des autres en utilisant des espaces d'adressage distincts. Les appels des processus utilisateur vers le noyau sont régulés en leur demandant d'utiliser l'une des méthodes d'appel système décrites ci-dessus.

Une autre approche consiste à utiliser une protection basée sur le langage. Dans un système de protection basé sur le langage , le noyau autorisera uniquement l'exécution du code produit par un compilateur de langage de confiance . Le langage peut alors être conçu de telle sorte qu'il soit impossible pour le programmeur de lui ordonner de faire quelque chose qui violerait une exigence de sécurité.

Les avantages de cette approche incluent :

• Il n'est pas nécessaire d'avoir des espaces d'adressage séparés. Le basculement entre les espaces d'adressage est une opération lente qui entraîne une surcharge importante. De nombreux travaux d'optimisation sont actuellement effectués afin d'éviter les basculements inutiles dans les systèmes d'exploitation actuels. Le basculement est totalement inutile dans un système de protection basé sur le langage, car tout le code peut fonctionner en toute sécurité dans le même espace d'adressage.
• Flexibilité. Tout schéma de protection pouvant être conçu pour être exprimé via un langage de programmation peut être implémenté à l'aide de cette méthode. Les modifications apportées au schéma de protection (par exemple, d'un système hiérarchique à un système basé sur les capacités) ne nécessitent pas de nouveau matériel.

Les inconvénients incluent :

• Temps de démarrage des applications plus long. Les applications doivent être vérifiées au démarrage pour s'assurer qu'elles ont été compilées par le compilateur approprié, ou peuvent nécessiter une recompilation à partir du code source ou du bytecode .
• Systèmes de types inflexibles . Sur les systèmes traditionnels, les applications effectuent fréquemment des opérations qui ne sont pas sécurisées en termes de type . De telles opérations ne peuvent pas être autorisées dans un système de protection basé sur le langage, ce qui signifie que les applications peuvent devoir être réécrites et peuvent, dans certains cas, entraîner une perte de performances.

Parmi les exemples de systèmes dotés d'une protection basée sur la langue, on peut citer JX et Singularity de Microsoft .

Edsger Dijkstra a prouvé que d'un point de vue logique, les opérations de verrouillage et de déverrouillage atomiques opérant sur des sémaphores binaires sont des primitives suffisantes pour exprimer toute fonctionnalité de coopération de processus. Cependant, cette approche est généralement considérée comme manquant de sécurité et d'efficacité, alors qu'une approche de transmission de messages est plus flexible. Un certain nombre d'autres approches (de niveau inférieur ou supérieur) sont également disponibles, de nombreux noyaux modernes prenant en charge des systèmes tels que la mémoire partagée et les appels de procédures à distance .

L'idée d'un noyau dans lequel les périphériques d'E/S sont traités de manière uniforme avec d'autres processus, en tant que processus coopérants parallèles, a été proposée et mise en œuvre pour la première fois par Brinch Hansen (bien que des idées similaires aient été suggérées en 1967 ). Dans la description de Hansen, les processus « communs » sont appelés processus internes , tandis que les périphériques d'E/S sont appelés processus externes .

Tout comme pour la mémoire physique, le fait d'autoriser les applications à accéder directement aux ports et aux registres du contrôleur peut entraîner un dysfonctionnement du contrôleur ou un blocage du système. En fonction de la complexité du périphérique, certains périphériques peuvent devenir étonnamment complexes à programmer et utiliser plusieurs contrôleurs différents. Pour cette raison, il est important de fournir une interface plus abstraite pour gérer le périphérique. Cette interface est normalement réalisée par un pilote de périphérique ou une couche d'abstraction matérielle. Les applications ont souvent besoin d'accéder à ces périphériques. Le noyau doit maintenir la liste de ces périphériques en interrogeant le système d'une manière ou d'une autre. Cela peut se faire via le BIOS ou via l'un des différents bus système (tels que PCI/PCIE ou USB). En prenant l'exemple d'un pilote vidéo, lorsqu'une application demande une opération sur un périphérique, comme l'affichage d'un caractère, le noyau doit envoyer cette demande au pilote vidéo actif actuel. Le pilote vidéo, à son tour, doit exécuter cette demande. Il s'agit d'un exemple de communication interprocessus (IPC).

Les tâches et fonctionnalités énumérées ci-dessus peuvent être fournies de nombreuses manières qui diffèrent les unes des autres en termes de conception et de mise en œuvre.

Le principe de séparation du mécanisme et de la politique constitue la différence substantielle entre la philosophie des noyaux micro et monolithiques. Ici, un mécanisme est le support qui permet la mise en œuvre de nombreuses politiques différentes, tandis qu'une politique est un « mode de fonctionnement » particulier. Exemple :

• Mécanisme : Les tentatives de connexion des utilisateurs sont acheminées vers un serveur d'autorisation
• Politique : le serveur d'autorisation requiert un mot de passe qui est vérifié par rapport aux mots de passe stockés dans une base de données

Étant donné que le mécanisme et la politique sont séparés, la politique peut être facilement modifiée pour, par exemple, exiger l'utilisation d'un jeton de sécurité .

Dans un micro-noyau minimal, seules quelques politiques très basiques sont incluses, et ses mécanismes permettent à ce qui s'exécute au-dessus du noyau (la partie restante du système d'exploitation et les autres applications) de décider quelles politiques adopter (comme la gestion de la mémoire, la planification des processus de haut niveau, la gestion du système de fichiers, etc.). Un noyau monolithique a plutôt tendance à inclure de nombreuses politiques, limitant ainsi le reste du système à s'appuyer sur elles.

Per Brinch Hansen a présenté des arguments en faveur de la séparation entre mécanisme et politique. L'incapacité à respecter correctement cette séparation est l'une des principales causes du manque d'innovation substantielle dans les systèmes d'exploitation existants, un problème courant dans l'architecture informatique. La conception monolithique est induite par l'approche architecturale de protection « mode noyau »/« mode utilisateur » (techniquement appelée domaines de protection hiérarchiques ), qui est courante dans les systèmes commerciaux conventionnels ; en fait, chaque module nécessitant une protection est donc de préférence inclus dans le noyau. Ce lien entre conception monolithique et « mode privilégié » peut être ramené à la question clé de la séparation mécanisme-politique ; en fait, l'approche architecturale du « mode privilégié » fusionne le mécanisme de protection avec les politiques de sécurité, tandis que l'approche architecturale alternative majeure, l'adressage basé sur les capacités , fait clairement la distinction entre les deux, conduisant naturellement à une conception de micro-noyau (voir Séparation de la protection et de la sécurité ).

Alors que les noyaux monolithiques exécutent tout leur code dans le même espace d'adressage ( espace noyau ), les micro-noyaux tentent d'exécuter la plupart de leurs services dans l'espace utilisateur, dans le but d'améliorer la maintenabilité et la modularité de la base de code. La plupart des noyaux n'entrent pas exactement dans l'une de ces catégories, mais se situent plutôt entre ces deux conceptions. On les appelle noyaux hybrides . Des conceptions plus exotiques telles que les nano-noyaux et les exokernels sont disponibles, mais sont rarement utilisées pour les systèmes de production. L' hyperviseur Xen , par exemple, est un exokernel.

Dans un noyau monolithique, tous les services du système d'exploitation s'exécutent avec le thread principal du noyau, résidant ainsi dans la même zone mémoire. Cette approche fournit un accès matériel riche et puissant. Le développeur UNIX Ken Thompson a déclaré qu'il est « à son avis plus facile d'implémenter un noyau monolithique ». Les principaux inconvénients des noyaux monolithiques sont les dépendances entre les composants du système (un bug dans un pilote de périphérique peut faire planter l'ensemble du système) et le fait que les noyaux volumineux peuvent devenir très difficiles à maintenir ; Thompson a également déclaré qu'il est « également plus facile pour [un noyau monolithique] de se transformer rapidement en un désordre lorsqu'il est modifié ».

Les noyaux monolithiques, traditionnellement utilisés par les systèmes d'exploitation de type Unix, contiennent toutes les fonctions de base du système d'exploitation et les pilotes de périphériques. Un noyau monolithique est un programme unique qui contient tout le code nécessaire pour effectuer toutes les tâches liées au noyau. Chaque partie à laquelle la plupart des programmes peuvent accéder et qui ne peut pas être placée dans une bibliothèque se trouve dans l'espace noyau : pilotes de périphériques, planificateur, gestion de la mémoire, systèmes de fichiers et piles réseau. De nombreux appels système sont fournis aux applications pour leur permettre d'accéder à tous ces services. Un noyau monolithique, bien qu'initialement chargé de sous-systèmes qui peuvent ne pas être nécessaires, peut être réglé à un point où il est aussi rapide ou plus rapide que celui qui a été spécifiquement conçu pour le matériel, bien que plus pertinent dans un sens général.

Les noyaux monolithiques modernes, tels que le noyau Linux , le noyau FreeBSD , le noyau AIX , le noyau HP-UX et le noyau Solaris , qui appartiennent tous à la catégorie des systèmes d'exploitation de type Unix, prennent en charge les modules de noyau chargeables , permettant aux modules d'être chargés dans le noyau au moment de l'exécution, permettant une extension facile des capacités du noyau selon les besoins, tout en aidant à minimiser la quantité de code exécuté dans l'espace du noyau.

La plupart des opérations dans le noyau monolithique sont effectuées via des appels système. Il s'agit d'interfaces, généralement conservées dans une structure tabulaire, qui accèdent à certains sous-systèmes du noyau, comme les opérations sur disque. Les appels sont essentiellement effectués dans les programmes et une copie vérifiée de la requête est transmise via l'appel système. Par conséquent, il n'y a pas de très long trajet à parcourir. Le noyau Linux monolithique peut être extrêmement petit, non seulement en raison de sa capacité à charger dynamiquement des modules, mais aussi en raison de sa facilité de personnalisation. En fait, certaines versions sont suffisamment petites pour s'adapter à un grand nombre d'utilitaires et d'autres programmes sur une seule disquette et fournir néanmoins un système d'exploitation entièrement fonctionnel (l'une des plus populaires étant muLinux ). Cette capacité à miniaturiser son noyau a également conduit à une croissance rapide de l'utilisation de Linux dans les systèmes embarqués .

Ces types de noyaux se composent des fonctions principales du système d'exploitation et des pilotes de périphériques avec la possibilité de charger des modules lors de l'exécution. Ils fournissent des abstractions riches et puissantes du matériel sous-jacent. Ils fournissent un petit ensemble d'abstractions matérielles simples et utilisent des applications appelées serveurs pour fournir davantage de fonctionnalités. Cette approche particulière définit une interface virtuelle de haut niveau sur le matériel, avec un ensemble d'appels système pour implémenter des services du système d'exploitation tels que la gestion des processus, la concurrence et la gestion de la mémoire dans plusieurs modules qui s'exécutent en mode superviseur. Cette conception présente plusieurs défauts et limitations :

• Le codage dans le noyau peut être difficile, en partie parce qu'il est impossible d'utiliser des bibliothèques communes (comme une libc complète ) et parce qu'il faut utiliser un débogueur au niveau source comme gdb . Le redémarrage de l'ordinateur est souvent nécessaire. Ce n'est pas seulement un problème de commodité pour les développeurs. Lorsque le débogage est plus difficile et que les difficultés deviennent plus fortes, il devient plus probable que le code soit plus « bogué ».
• Les bugs dans une partie du noyau ont des effets secondaires importants ; étant donné que chaque fonction du noyau dispose de tous les privilèges, un bug dans une fonction peut corrompre la structure de données d'une autre partie du noyau, totalement indépendante, ou de tout programme en cours d'exécution.
• Les noyaux deviennent souvent très gros et difficiles à entretenir.
• Même si les modules assurant ces opérations sont séparés de l'ensemble, l'intégration du code est étroite et difficile à réaliser correctement.
• Étant donné que les modules fonctionnent dans le même espace d’adressage , un bug peut faire tomber l’ensemble du système.

Le micro-noyau (également abrégé μK ou uK) est le terme décrivant une approche de conception de système d'exploitation par laquelle la fonctionnalité du système est déplacée hors du « noyau » traditionnel vers un ensemble de « serveurs » qui communiquent via un noyau « minimal », laissant le moins possible dans « l'espace système » et le plus possible dans « l'espace utilisateur ». Un micro-noyau conçu pour une plate-forme ou un appareil spécifique n'aura jamais que ce dont il a besoin pour fonctionner. L'approche du micro-noyau consiste à définir une abstraction simple sur le matériel, avec un ensemble de primitives ou d'appels système pour implémenter des services OS minimaux tels que la gestion de la mémoire , le multitâche et la communication interprocessus . D'autres services, y compris ceux normalement fournis par le noyau, tels que la mise en réseau , sont implémentés dans des programmes en espace utilisateur, appelés serveurs . Les micro-noyaux sont plus faciles à maintenir que les noyaux monolithiques, mais le grand nombre d'appels système et de changements de contexte peut ralentir le système car ils génèrent généralement plus de surcharge que les appels de fonction simples.

Seules les parties qui nécessitent réellement d'être en mode privilégié se trouvent dans l'espace noyau : IPC (Inter-Process Communication), planificateur de base ou primitives de planification, gestion de la mémoire de base, primitives d'E/S de base. De nombreuses parties critiques s'exécutent désormais dans l'espace utilisateur : le planificateur complet, la gestion de la mémoire, les systèmes de fichiers et les piles réseau. Les micro-noyaux ont été inventés en réaction à la conception traditionnelle du noyau "monolithique", selon laquelle toutes les fonctionnalités du système étaient placées dans un programme statique unique exécuté dans un mode "système" spécial du processeur. Dans le micro-noyau, seules les tâches les plus fondamentales sont effectuées, comme la possibilité d'accéder à une partie (pas nécessairement à la totalité) du matériel, la gestion de la mémoire et la coordination du passage des messages entre les processus. Certains systèmes qui utilisent des micro-noyaux sont QNX et HURD. Dans le cas de QNX et Hurd, les sessions utilisateur peuvent être des instantanés entiers du système lui-même ou des vues, comme on l'appelle. L'essence même de l'architecture du micro-noyau illustre certains de ses avantages :

• Plus facile à entretenir
• Les correctifs peuvent être testés dans une instance distincte, puis échangés pour prendre le relais d'une instance de production.
• Le temps de développement est rapide et les nouveaux logiciels peuvent être testés sans avoir à redémarrer le noyau.
• Plus de persistance en général, si une instance devient incontrôlable, il est souvent possible de la remplacer par un miroir opérationnel.

La plupart des micro-noyaux utilisent un système de transmission de messages pour gérer les requêtes d'un serveur à un autre. Le système de transmission de messages fonctionne généralement sur la base d'un port avec le micro-noyau. Par exemple, si une demande de mémoire supplémentaire est envoyée, un port est ouvert avec le micro-noyau et la demande est envoyée. Une fois dans le micro-noyau, les étapes sont similaires aux appels système. L'idée était d'apporter de la modularité à l'architecture du système, ce qui entraînerait un système plus propre, plus facile à déboguer ou à modifier dynamiquement, personnalisable selon les besoins des utilisateurs et plus performant. Ils font partie des systèmes d'exploitation comme GNU Hurd , MINIX , MkLinux , QNX et Redox OS . Bien que les micro-noyaux soient très petits en eux-mêmes, en combinaison avec tout le code auxiliaire requis, ils sont en fait souvent plus gros que les noyaux monolithiques. Les partisans des noyaux monolithiques soulignent également que la structure à deux niveaux des systèmes de micro-noyaux, dans laquelle la majeure partie du système d'exploitation n'interagit pas directement avec le matériel, crée un coût non négligeable en termes d'efficacité du système. Ces types de noyaux ne fournissent généralement que les services minimaux tels que la définition des espaces d'adressage mémoire, la communication interprocessus (IPC) et la gestion des processus. Les autres fonctions telles que l'exécution des processus matériels ne sont pas gérées directement par les micro-noyaux. Les partisans des micro-noyaux soulignent que ces noyaux monolithiques présentent l'inconvénient qu'une erreur dans le noyau peut provoquer le blocage de l'ensemble du système. Cependant, avec un micro-noyau, si un processus du noyau se bloque, il est toujours possible d'empêcher un blocage de l'ensemble du système en redémarrant simplement le service qui a provoqué l'erreur.

D'autres services fournis par le noyau, comme la mise en réseau, sont implémentés dans des programmes en espace utilisateur appelés serveurs . Les serveurs permettent de modifier le système d'exploitation en démarrant et en arrêtant simplement des programmes. Sur une machine sans prise en charge réseau, par exemple, le serveur réseau n'est pas démarré. La tâche consistant à entrer et sortir du noyau pour déplacer des données entre les différentes applications et serveurs crée une surcharge qui nuit à l'efficacité des micro-noyaux par rapport aux noyaux monolithiques.

Le micro-noyau présente cependant des inconvénients. En voici quelques-uns :

• Empreinte mémoire d'exécution plus importante
• Des logiciels supplémentaires pour l'interfaçage sont nécessaires, il existe un risque de perte de performances.
• Les bogues de messagerie peuvent être plus difficiles à corriger en raison du trajet plus long qu'ils doivent parcourir par rapport à la copie unique dans un noyau monolithique.
• La gestion des processus en général peut être très compliquée.

Les inconvénients des micro-noyaux sont extrêmement liés au contexte. Par exemple, ils fonctionnent bien pour les petits systèmes à usage unique (et critiques) car si peu de processus doivent être exécutés, les complications liées à la gestion des processus sont efficacement atténuées.

Un micro-noyau permet d'implémenter la partie restante du système d'exploitation sous forme de programme d'application normal écrit dans un langage de haut niveau , et d'utiliser différents systèmes d'exploitation sur le même noyau inchangé. Il est également possible de basculer dynamiquement entre les systèmes d'exploitation et d'en avoir plusieurs actifs simultanément.

Au fur et à mesure que le noyau de l'ordinateur grandit, la taille et la vulnérabilité de sa base de calcul de confiance augmentent également . En plus de réduire la sécurité, il y a le problème de l'augmentation de l' empreinte mémoire . Ce problème est atténué dans une certaine mesure par le perfectionnement du système de mémoire virtuelle , mais toutes les architectures informatiques ne prennent pas en charge la mémoire virtuelle. Pour réduire l'empreinte du noyau, une édition approfondie doit être effectuée pour supprimer soigneusement le code inutile, ce qui peut être très difficile avec des interdépendances non évidentes entre les parties d'un noyau avec des millions de lignes de code.

Au début des années 1990, en raison des divers défauts des noyaux monolithiques par rapport aux micro-noyaux, les noyaux monolithiques étaient considérés comme obsolètes par pratiquement tous les chercheurs en systèmes d'exploitation. En conséquence, la conception de Linux comme un noyau monolithique plutôt qu'un micro-noyau a été le sujet d'un célèbre débat entre Linus Torvalds et Andrew Tanenbaum . débat Tanenbaum-Torvalds ont du mérite .

Les noyaux monolithiques sont conçus pour avoir tout leur code dans le même espace d'adressage ( espace noyau ), ce qui, selon certains développeurs, est nécessaire pour augmenter les performances du système. Certains développeurs soutiennent également que les systèmes monolithiques sont extrêmement efficaces s'ils sont bien écrits. Le modèle monolithique a tendance à être plus efficace grâce à l'utilisation de la mémoire partagée du noyau, plutôt que le système IPC plus lent des conceptions de micro-noyaux, qui est généralement basé sur le passage de messages .

Les performances des micro-noyaux étaient médiocres dans les années 1980 et au début des années 1990. Cependant, les études qui ont mesuré empiriquement les performances de ces micro-noyaux n'ont pas analysé les raisons de cette inefficacité. Les explications de ces données ont été laissées au « folklore », avec l'hypothèse qu'elles étaient dues à la fréquence accrue des commutations du « mode noyau » au « mode utilisateur », à la fréquence accrue des communications interprocessus et à la fréquence accrue des commutations de contexte .

En fait, comme on l'avait deviné en 1995, les raisons des faibles performances des micro-noyaux pourraient tout aussi bien être : (1) une inefficacité réelle de l' approche globale du micro-noyau , (2) les concepts particuliers mis en œuvre dans ces micro-noyaux et (3) l' implémentation particulière de ces concepts. Il restait donc à étudier si la solution pour construire un micro-noyau efficace était, contrairement aux tentatives précédentes, d'appliquer les bonnes techniques de construction.

À l'autre extrémité, l' architecture des domaines de protection hiérarchiques qui conduit à la conception d'un noyau monolithique présente un inconvénient de performance important chaque fois qu'il y a une interaction entre différents niveaux de protection (c'est-à-dire lorsqu'un processus doit manipuler une structure de données à la fois en « mode utilisateur » et en « mode superviseur »), car cela nécessite une copie des messages par valeur .

Les noyaux hybrides sont utilisés dans la plupart des systèmes d'exploitation commerciaux tels que Microsoft Windows NT 3.1, NT 3.5, NT 3.51, NT 4.0, 2000, XP, Vista, 7, 8, 8.1 et 10. Le système d'exploitation macOS d' Apple utilise un noyau hybride appelé XNU , qui est basé sur le code du noyau Mach d' OSF/1 (OSFMK 7.3) et du noyau monolithique de FreeBSD . Les noyaux hybrides sont similaires aux micro-noyaux, sauf qu'ils incluent du code supplémentaire dans l'espace noyau pour augmenter les performances. Ces noyaux représentent un compromis qui a été mis en œuvre par certains développeurs pour prendre en compte les principaux avantages des noyaux monolithiques et micro-noyaux. Ces types de noyaux sont des extensions de micro-noyaux avec certaines propriétés des noyaux monolithiques. Contrairement aux noyaux monolithiques, ces types de noyaux ne peuvent pas charger seuls des modules lors de l'exécution. Cela implique l'exécution de certains services (tels que la pile réseau ou le système de fichiers ) dans l'espace noyau pour réduire la surcharge de performances d'un micro-noyau traditionnel, tout en exécutant le code du noyau (tel que les pilotes de périphériques) en tant que serveurs dans l'espace utilisateur.

De nombreux noyaux traditionnellement monolithiques ajoutent désormais au moins (ou utilisent) la capacité de module. Le plus connu de ces noyaux est le noyau Linux. Le noyau modulaire peut essentiellement avoir des parties intégrées dans le noyau binaire ou les binaires qui se chargent en mémoire à la demande. Un module contaminé par du code a le potentiel de déstabiliser un noyau en cours d'exécution. Il est possible d'écrire un pilote pour un micro-noyau dans un espace mémoire complètement séparé et de le tester avant de le "mettre" en service. Lorsqu'un module du noyau est chargé, il accède à l'espace mémoire de la partie monolithique en y ajoutant ce dont il a besoin, ouvrant ainsi la porte à une éventuelle pollution. Voici quelques avantages du noyau modulaire (ou) hybride :

• Temps de développement plus rapide pour les pilotes pouvant fonctionner à partir de modules. Aucun redémarrage n'est nécessaire pour les tests (à condition que le noyau ne soit pas déstabilisé).
• Capacité à la demande par rapport au temps passé à recompiler un noyau entier pour des éléments tels que de nouveaux pilotes ou sous-systèmes.
• Intégration plus rapide de technologies tierces (liées au développement mais néanmoins pertinentes en elles-mêmes).

Les modules communiquent généralement avec le noyau à l'aide d'une interface de module. L'interface est généralisée (bien que spécifique à un système d'exploitation donné), il n'est donc pas toujours possible d'utiliser des modules. Souvent, les pilotes de périphériques peuvent nécessiter plus de flexibilité que ce que permet l'interface du module. Essentiellement, il s'agit de deux appels système et souvent les contrôles de sécurité qui ne doivent être effectués qu'une seule fois dans le noyau monolithique peuvent être effectués deux fois. Certains des inconvénients de l'approche modulaire sont les suivants :

• Avec davantage d'interfaces à traverser, la possibilité d'une augmentation des bugs existe (ce qui implique davantage de failles de sécurité).
• La maintenance des modules peut être déroutante pour certains administrateurs lorsqu'ils sont confrontés à des problèmes tels que les différences de symboles.

Un nano-noyau délègue pratiquement tous les services – y compris les plus basiques comme les contrôleurs d’interruption ou le minuteur – aux pilotes de périphériques pour rendre les besoins en mémoire du noyau encore plus faibles qu’un micro-noyau traditionnel.

Les exokernels sont une approche encore expérimentale de la conception de systèmes d'exploitation. Ils diffèrent des autres types de noyaux en limitant leurs fonctionnalités à la protection et au multiplexage du matériel brut, sans fournir d'abstractions matérielles sur lesquelles développer des applications. Cette séparation de la protection du matériel et de la gestion du matériel permet aux développeurs d'applications de déterminer comment utiliser le matériel disponible de la manière la plus efficace pour chaque programme spécifique.

Les exokernels sont en eux-mêmes extrêmement petits. Cependant, ils sont accompagnés de systèmes d'exploitation de bibliothèque (voir aussi unikernel ), fournissant aux développeurs d'applications les fonctionnalités d'un système d'exploitation conventionnel. Cela revient à ce que chaque utilisateur écrive son propre reste du noyau à partir de presque zéro, ce qui est une tâche très risquée, complexe et assez intimidante - en particulier dans un environnement orienté production avec des contraintes de temps, c'est pourquoi les exokernels n'ont jamais pris. Un avantage majeur des systèmes basés sur des exokernels est qu'ils peuvent incorporer plusieurs systèmes d'exploitation de bibliothèque, chacun exportant une API différente , par exemple une pour le développement d'interface utilisateur de haut niveau et une pour le contrôle en temps réel .

Un système d'exploitation multi-noyau traite une machine multi-cœur comme un réseau de cœurs indépendants, comme s'il s'agissait d'un système distribué . Il ne suppose pas de mémoire partagée mais implémente plutôt des communications inter-processus sous forme de transmission de messages . Barrelfish a été le premier système d'exploitation à être décrit comme multi-noyau.

À proprement parler, un système d'exploitation (et donc un noyau) n'est pas nécessaire pour faire fonctionner un ordinateur. Les programmes peuvent être directement chargés et exécutés sur la machine « bare metal » , à condition que les auteurs de ces programmes soient prêts à travailler sans aucune abstraction matérielle ni support du système d'exploitation. La plupart des premiers ordinateurs fonctionnaient de cette manière dans les années 1950 et au début des années 1960, et étaient réinitialisés et rechargés entre l'exécution de différents programmes. Finalement, de petits programmes auxiliaires tels que des chargeurs de programmes et des débogueurs étaient laissés en mémoire entre les exécutions, ou chargés à partir de la ROM . Au fur et à mesure de leur développement, ils ont formé la base de ce qui est devenu les premiers noyaux de systèmes d'exploitation. L'approche « bare metal » est encore utilisée aujourd'hui sur certaines consoles de jeux vidéo et systèmes embarqués , mais en général, les ordinateurs plus récents utilisent des systèmes d'exploitation et des noyaux modernes.

En 1969, le système de multiprogrammation RC 4000 a introduit la philosophie de conception du système d'un petit noyau « sur lequel des systèmes d'exploitation à des fins différentes pourraient être construits de manière ordonnée », ce qui serait appelé l'approche micro-noyau.

Au cours de la décennie précédant Unix , les ordinateurs avaient énormément gagné en puissance, à tel point que les opérateurs informatiques cherchaient de nouvelles façons d'inciter les gens à utiliser leur temps libre sur leurs machines. L'une des principales évolutions de cette époque était le partage du temps , selon lequel un certain nombre d'utilisateurs obtenaient de petites tranches de temps d'ordinateur, à un rythme auquel ils semblaient être chacun connectés à leur propre machine, plus lente.

Le développement des systèmes à temps partagé a entraîné un certain nombre de problèmes. L'un d'eux était que les utilisateurs, en particulier dans les universités où les systèmes étaient développés, semblaient vouloir pirater le système pour obtenir plus de temps CPU . Pour cette raison, la sécurité et le contrôle d'accès sont devenus un objectif majeur du projet Multics en 1965. Un autre problème récurrent était la gestion appropriée des ressources informatiques : les utilisateurs passaient la plupart de leur temps à regarder le terminal et à réfléchir à ce qu'ils devaient saisir au lieu d'utiliser réellement les ressources de l'ordinateur, et un système à temps partagé devait donner le temps CPU à un utilisateur actif pendant ces périodes. Enfin, les systèmes offraient généralement une hiérarchie de mémoire sur plusieurs couches, et le partitionnement de cette ressource coûteuse a conduit à des développements majeurs dans les systèmes de mémoire virtuelle .

Le Commodore Amiga est sorti en 1985 et a été l'un des premiers ordinateurs personnels à proposer une architecture de noyau avancée, et certainement l'un des plus performants. Le composant exécutif du noyau AmigaOS, exec.library , utilise une conception de transmission de messages par micro-noyau, mais d'autres composants du noyau, comme graphics.library , ont un accès direct au matériel. Il n'y a pas de protection de la mémoire et le noyau fonctionne presque toujours en mode utilisateur. Seules des actions spéciales sont exécutées en mode noyau et les applications en mode utilisateur peuvent demander au système d'exploitation d'exécuter leur code en mode noyau.

Au cours de la phase de conception d' Unix , les programmeurs ont décidé de modéliser chaque périphérique de haut niveau comme un fichier , car ils pensaient que le but du calcul était la transformation des données .

Par exemple, les imprimantes étaient représentées comme un « fichier » à un emplacement connu : lorsque des données étaient copiées dans le fichier, elles étaient imprimées. D’autres systèmes, pour fournir une fonctionnalité similaire, avaient tendance à virtualiser les périphériques à un niveau inférieur, c’est-à-dire que les périphériques et les fichiers étaient des instances d’un concept de niveau inférieur . La virtualisation du système au niveau du fichier permettait aux utilisateurs de manipuler l’ensemble du système à l’aide de leurs utilitaires et concepts de gestion de fichiers existants , simplifiant considérablement les opérations. Dans le prolongement du même paradigme, Unix permet aux programmeurs de manipuler des fichiers à l’aide d’une série de petits programmes, en utilisant le concept de tubes , qui permettait aux utilisateurs d’effectuer des opérations par étapes, en alimentant un fichier via une chaîne d’outils à usage unique. Bien que le résultat final soit le même, l’utilisation de programmes plus petits de cette manière augmentait considérablement la flexibilité ainsi que la facilité de développement et d’utilisation, permettant à l’utilisateur de modifier son flux de travail en ajoutant ou en supprimant un programme de la chaîne.

Dans le modèle Unix, le système d'exploitation se compose de deux parties : d'abord, l'énorme collection de programmes utilitaires qui pilotent la plupart des opérations ; ensuite, le noyau qui exécute les programmes. Sous Unix, du point de vue de la programmation, la distinction entre les deux est assez mince ; le noyau est un programme, exécuté en mode superviseur, qui agit comme un chargeur de programme et un superviseur pour les petits programmes utilitaires constituant le reste du système, et pour fournir des services de verrouillage et d'E/S pour ces programmes ; au-delà de cela, le noyau n'intervient pas du tout dans l'espace utilisateur .

Au fil des années, le modèle informatique a changé et le traitement Unix de tout comme un fichier ou un flux d'octets n'était plus aussi universellement applicable qu'auparavant. Bien qu'un terminal puisse être traité comme un fichier ou un flux d'octets, sur lequel on peut imprimer ou lire, il ne semble pas en être de même pour une interface utilisateur graphique . La mise en réseau posait un autre problème. Même si la communication réseau peut être comparée à l'accès aux fichiers, l'architecture orientée paquets de bas niveau traitait des blocs de données discrets et non des fichiers entiers. À mesure que les capacités des ordinateurs augmentaient, Unix est devenu de plus en plus encombré de code. C'est aussi parce que la modularité du noyau Unix est extrêmement évolutive. Alors que les noyaux pouvaient contenir 100 000 lignes de code dans les années 70 et 80, les noyaux comme Linux , des successeurs modernes d'Unix comme GNU , en comptent plus de 13 millions.

Les dérivés modernes d'Unix sont généralement basés sur des noyaux monolithiques à chargement de modules. On peut citer comme exemples le noyau Linux des nombreuses distributions de GNU , IBM AIX , ainsi que les noyaux variantes de Berkeley Software Distribution tels que FreeBSD , DragonFly BSD , OpenBSD , NetBSD et macOS . En dehors de ces alternatives, les développeurs amateurs entretiennent une communauté active de développement de systèmes d'exploitation , peuplée de noyaux de passe-temps auto-écrits qui finissent généralement par partager de nombreuses fonctionnalités avec les noyaux Linux, FreeBSD, DragonflyBSD, OpenBSD ou NetBSD et/ou sont compatibles avec eux.

Apple a lancé pour la première fois son système d'exploitation Mac OS classique en 1984, fourni avec son ordinateur personnel Macintosh . Apple est passé à une conception nano-noyau dans Mac OS 8.6. Par contre, le macOS moderne (initialement appelé Mac OS X) est basé sur Darwin , qui utilise un noyau hybride appelé XNU , qui a été créé en combinant le noyau 4.3BSD et le noyau Mach .

Microsoft Windows a été lancé pour la première fois en 1985 en tant que module complémentaire de MS-DOS . En raison de sa dépendance à un autre système d'exploitation, les premières versions de Windows, avant Windows 95, étaient considérées comme un environnement d'exploitation (à ne pas confondre avec un système d'exploitation ). Cette gamme de produits a continué d'évoluer au cours des années 1980 et 1990, avec la série Windows 9x ajoutant l'adressage 32 bits et le multitâche préemptif ; mais s'est terminée avec la sortie de Windows Me en 2000.

Microsoft a également développé Windows NT , un système d'exploitation avec une interface très similaire, mais destiné aux utilisateurs haut de gamme et professionnels. Cette ligne a débuté avec la sortie de Windows NT 3.1 en 1993 et ​​a été présentée aux utilisateurs généraux avec la sortie de Windows XP en octobre 2001, remplaçant Windows 9x par un système d'exploitation complètement différent et beaucoup plus sophistiqué. C'est cette ligne qui se poursuit avec Windows 11 .

L' architecture du noyau de Windows NT est considérée comme un noyau hybride car le noyau lui-même contient des tâches telles que le gestionnaire de fenêtres et les gestionnaires IPC, avec un modèle de sous-système en couches client/serveur. Il a été conçu comme un micro-noyau modifié , car le noyau de Windows NT a été influencé par le micro-noyau Mach mais ne répond pas à tous les critères d'un micro-noyau pur.

Un programme de supervision ou superviseur est un programme informatique , généralement intégré à un système d'exploitation , qui contrôle l'exécution d'autres routines et régule la planification du travail , les opérations d'entrée/sortie , les actions d'erreur et des fonctions similaires et régule le flux de travail dans un système de traitement de données .

Historiquement, ce terme était essentiellement associé à la gamme de systèmes d'exploitation mainframe d' IBM , à commencer par OS/360 . Dans les autres systèmes d'exploitation, le superviseur est généralement appelé noyau.

Dans les années 1970, IBM a encore davantage isolé l' état superviseur du matériel, ce qui a donné naissance à un hyperviseur qui permettait une virtualisation complète , c'est-à-dire la capacité d'exécuter plusieurs systèmes d'exploitation sur la même machine de manière totalement indépendante les uns des autres. C'est ainsi que le premier système de ce type a été appelé machine virtuelle ou VM .

Bien que Mach , développé par Richard Rashid à l'université Carnegie Mellon , soit le micro-noyau polyvalent le plus connu, d'autres micro-noyaux ont été développés avec des objectifs plus spécifiques. La famille des micro-noyaux L4 (principalement les noyaux L3 et L4) a été créée pour démontrer que les micro-noyaux ne sont pas nécessairement lents. Des implémentations plus récentes telles que Fiasco et Pistachio sont capables d'exécuter Linux à côté d'autres processus L4 dans des espaces d'adressage séparés.

De plus, QNX est un micro-noyau principalement utilisé dans les systèmes embarqués , et le logiciel open source MINIX , bien que créé à l'origine à des fins éducatives, se concentre désormais sur le fait d'être un système d'exploitation micro-noyau hautement fiable et auto-réparateur .