Noyau de systeme d'exploitation

ï»ż
Noyau de systeme d'exploitation

Noyau de systĂšme d'exploitation

Page d'aide sur l'homonymie Pour les articles homonymes, voir noyau.

Un noyau de systĂšme d’exploitation (abrĂ©gĂ© noyau, ou kernel en anglais, de l'allemand kern), est la partie fondamentale de certains systĂšmes d’exploitation. Il gĂšre les ressources de l’ordinateur et permet aux diffĂ©rents composants — matĂ©riels et logiciels — de communiquer entre eux.

En tant que partie du systĂšme d’exploitation, le noyau fournit des mĂ©canismes d’abstraction du matĂ©riel, notamment de la mĂ©moire, du (ou des) processeur(s), et des Ă©changes d’informations entre logiciels et pĂ©riphĂ©riques matĂ©riels. Le noyau autorise aussi diverses abstractions logicielles et facilite la communication entre les processus.

Le noyau d’un systĂšme d’exploitation est lui-mĂȘme un logiciel, mais ne peut cependant utiliser tous les mĂ©canismes d’abstraction qu’il fournit aux autres logiciels[1]. Son rĂŽle central impose par ailleurs des performances Ă©levĂ©es. Cela fait du noyau la partie la plus critique d’un systĂšme d’exploitation et rend sa conception et sa programmation particuliĂšrement dĂ©licates. Plusieurs techniques sont mises en Ɠuvre pour simplifier la programmation des noyaux tout en garantissant de bonnes performances.

Sommaire

Généralités

En informatique, le noyau d’un systĂšme d’exploitation est le logiciel qui assure :

  • la communication entre les logiciels et le matĂ©riel ;
  • la gestion des divers logiciels (tĂąches) d’une machine (lancement des programmes, ordonnancement
) ;
  • la gestion du matĂ©riel (mĂ©moire, processeur, pĂ©riphĂ©rique, stockage
).

La majoritĂ© des systĂšmes d’exploitation est construite autour de la notion de noyau. L’existence d’un noyau, c’est-Ă -dire d’un programme unique responsable de la communication entre le matĂ©riel et le logiciel, rĂ©sulte de compromis complexes portant sur des questions de performance, de sĂ©curitĂ© et d’architecture des processeurs.

L’existence d’un noyau prĂ©suppose[2] une partition virtuelle de la mĂ©moire vive physique en deux rĂ©gions disjointes, l’une Ă©tant rĂ©servĂ©e au noyau (l’espace noyau) et l’autre aux applications (l’espace utilisateur). Cette division fondamentale de l’espace mĂ©moire en un espace noyau et un espace utilisateur contribue beaucoup Ă  donner la forme et le contenu actuels des systĂšmes gĂ©nĂ©ralistes (Linux, Windows, Mac OS X, etc.). Le noyau a de grands pouvoirs sur l’utilisation des ressources matĂ©rielles, en particulier de la mĂ©moire. Elle structure Ă©galement le travail des dĂ©veloppeurs : le dĂ©veloppement de code dans l’espace noyau est a priori plus dĂ©licat que dans l’espace utilisateur car la mĂ©moire n’est pas protĂ©gĂ©e.

Le noyau offre ses fonctionnalitĂ©s (l’accĂšs aux ressources qu’il gĂšre) au travers des appels systĂšme. Il transmet ou interprĂšte les informations du matĂ©riel via des interruptions. C’est ce que l’on appelle les entrĂ©es et sorties.

Diverses abstractions de la notion d’application sont fournies par le noyau aux dĂ©veloppeurs. La plus courante est celle de processus (ou tĂąche). Le noyau du systĂšme d’exploitation n’est en lui-mĂȘme pas une tĂąche, mais un ensemble de routines pouvant ĂȘtre appelĂ©es par les diffĂ©rents processus pour effectuer des opĂ©rations requĂ©rant un certain niveau de privilĂšges. Les flots d’exĂ©cution dans le noyau sont des continuations des flots d’exĂ©cution des processus utilisateurs bloquĂ©s lorsqu’ils effectuent des appels systĂšmes. En gĂ©nĂ©ral, un processus bloquĂ© ne consomme pas de temps processeur, il est rĂ©veillĂ© par le processus systĂšme lorsque celui-ci se termine.

Un processeur est capable d’exĂ©cuter un seul processus, un multiprocesseur est capable de gĂ©rer autant de processus qu’il a de processeurs. Pour pallier cet inconvĂ©nient majeur, les noyaux multitĂąches permettent l’exĂ©cution de plusieurs processus sur un processeur, en partageant le temps du processeur entre les processus.

Lorsque plusieurs tĂąches doivent ĂȘtre exĂ©cutĂ©es de maniĂšre parallĂšle, un noyau multitĂąche s’appuie sur les notions de :

Les entrĂ©es et les sorties font l’objet d’un traitement spĂ©cifique par l’ordonnanceur.

SystĂšmes Ă  noyaux restreints

Il existe de nombreux noyaux aux fonctionnalités restreintes tels que les micro-noyaux, les systÚmes sans noyau (MS-DOS, CP/M) ou les exo-noyaux.

Ces systĂšmes sont gĂ©nĂ©ralement adaptĂ©s Ă  des applications trĂšs ciblĂ©es mais posent des problĂšmes variĂ©s (de sĂ©curitĂ© avec MS-DOS, de performances avec HURD ou QNX). La plupart d’entre eux sont actuellement inadaptĂ©s pour une utilisation gĂ©nĂ©raliste, dans des serveurs ou ordinateurs personnels.

Fonctions généralement remplies par un noyau

Les noyaux ont comme fonctions de base d’assurer le chargement et l’exĂ©cution des processus, de gĂ©rer les entrĂ©es/sorties et de proposer une interface entre l’espace noyau et les programmes de l’espace utilisateur.

À de rares exceptions, les noyaux ne sont pas limitĂ©s Ă  leurs fonctionnalitĂ©s de base. On trouve gĂ©nĂ©ralement dans les noyaux les fonctions des micro-noyaux : un gestionnaire de mĂ©moire et un ordonnanceur, ainsi que des fonctions de communication inter-processus.

En dehors de fonctions prĂ©cĂ©demment listĂ©es, de nombreux noyaux fournissent Ă©galement des fonctions moins fondamentales telles que la gestion des systĂšmes de fichiers ; plusieurs ordonnanceurs spĂ©cialisĂ©s (batch, temps rĂ©el, entrĂ©es/sorties, etc.) ; des notions de processus Ă©tendues telles que les processus lĂ©gers ; des supports rĂ©seaux (TCP/IP, PPP, pare-feu, etc.) ; des services rĂ©seau (NFS, etc.). Enfin, la plupart des noyaux fournissent Ă©galement des modĂšles de pilotes et des pilotes pour le matĂ©riel.

En dehors des fonctionnalitĂ©s de base, l’ensemble des fonctions des points suivants (y compris les pilotes matĂ©riels, les fonctions rĂ©seaux et systĂšmes de fichiers ou les services) n'est pas nĂ©cessairement fourni par un noyau de systĂšme d’exploitation. Ces fonctions du systĂšme d’exploitation peuvent ĂȘtre implantĂ©es tant dans l’espace utilisateur que dans le noyau lui-mĂȘme. Leur implantation dans le noyau est faite dans l’unique but d’augmenter les performances. En effet, suivant la conception du noyau, la mĂȘme fonction appelĂ©e depuis l’espace utilisateur ou l’espace noyau a un coĂ»t temporel notoirement diffĂ©rent. Si cet appel de fonction est frĂ©quent, il peut s’avĂ©rer utile d’intĂ©grer ces fonctions au noyau pour augmenter les performances.

Ces techniques sont utilisĂ©es pour pallier des dĂ©fauts des noyaux tels que les latences Ă©levĂ©es. Autant que possible, il est prĂ©fĂ©rable d’écrire un logiciel hors du noyau, dans l’espace utilisateur. En effet, l’écriture en espace noyau suppose l’absence de mĂ©canismes tels que la protection de la mĂ©moire. Il est donc plus complexe d’écrire un logiciel fonctionnant dans l’espace noyau que dans l’espace utilisateur, les bogues et failles de sĂ©curitĂ© sont bien plus dangereux.

Ordonnanceur

4 tùches ordonnancées. La tùche 3 est en priorité haute, la tùche 4 est en priorité faible. Ce diagramme est explicatif, en pratique les instructions ordonnées sont directement exécutées

L’ordonnanceur d’un systĂšme d’exploitation n’a de sens qu’en systĂšme multitĂąche. Il gĂšre l’ordre dans lequel les instructions de diffĂ©rentes tĂąches sont exĂ©cutĂ©es et est responsable de la sauvegarde et de la restauration du contexte des tĂąches (ce contexte est constituĂ© des registres processeurs), appelĂ©e Ă©galement commutation de contexte.

La plupart des ordonnanceurs modernes permettent d’indiquer sur quel processeur sont exĂ©cutĂ©es les tĂąches. Certains permettent Ă©galement de migrer des tĂąches sur d’autres machines d’une grappe de calcul.

L’algorithme d’ordonnancement dĂ©termine quelle tĂąche doit s’exĂ©cuter en prioritĂ© et sur quel processeur. Cet algorithme doit permettre d’utiliser efficacement les ressources de la machine.

L’ordonnancement peut ĂȘtre de type « coopĂ©ratif Â» : les tĂąches doivent ĂȘtre Ă©crites de maniĂšre Ă  coopĂ©rer les unes avec les autres et ainsi accepter leur suspension pour l’exĂ©cution d’une autre tĂąche. L’ordonnancement peut ĂȘtre Ă©galement de type prĂ©emptif : l’ordonnanceur a la responsabilitĂ© de l’interruption des tĂąches et du choix de la prochaine Ă  exĂ©cuter. Certains noyaux sont eux-mĂȘmes prĂ©emptifs : l’ordonnanceur peut interrompre le noyau lui-mĂȘme pour faire place Ă  une activitĂ© (typiquement, toujours dans le noyau) de prioritĂ© plus Ă©levĂ©e.

Gestionnaire de mémoire

Le gestionnaire de mĂ©moire est le sous-ensemble du systĂšme d’exploitation qui permet de gĂ©rer la mĂ©moire de l’ordinateur. Sa tĂąche la plus basique est d’allouer de la mĂ©moire Ă  des processus lorsqu’ils en ont besoin. Cette mĂ©moire allouĂ©e est par dĂ©faut propre au processus qui en fait la demande.

Gestionnaire de mémoire, espace utilisateur et espace noyau

Sur les noyaux rĂ©cents[3], le gestionnaire de mĂ©moire masque la localisation physique de la mĂ©moire (en mĂ©moire vive ou sur disque dur, dans l’espace de mĂ©moire paginĂ©e) et prĂ©sente au programme une mĂ©moire globale uniforme dite mĂ©moire virtuelle. Ainsi, tout processus croit manipuler une mĂ©moire "logique" qui a les propriĂ©tĂ©s suivantes[4] :

  • la mĂ©moire peut ĂȘtre Ă©tendue jusqu’aux capacitĂ©s thĂ©oriques de la machine[5] ;
  • la mĂ©moire est privĂ©e (protĂ©gĂ©e), un processus ne peut pas accĂ©der Ă  la mĂ©moire d’un autre processus (sauf allocations et autorisations spĂ©cifiques).

L’intĂ©rĂȘt de ne pas indiquer au processus l’emplacement physique des donnĂ©es est de permettre au gestionnaire de mĂ©moire de placer et dĂ©placer Ă  sa convenance les donnĂ©es en mĂ©moire, sans affecter les processus. Ces donnĂ©es peuvent notamment ĂȘtre fragmentĂ©es dans la mĂ©moire vive lorsqu’un processus demande un bloc de mĂ©moire d’une taille supĂ©rieure au plus grand bloc physique libre. Le contenu de la mĂ©moire peut aussi ĂȘtre migrĂ©. Cette migration est faite sur les diffĂ©rents supports mĂ©moires tels que dans la mĂ©moire physique (plus ou moins proche du processeur), dans la mĂ©moire paginĂ©e, dans la mĂ©moire accessible par rĂ©seaux (grappe de calcul).

La virtualisation de la mĂ©moire permet aussi une gestion optimiste des ressources : la mĂ©moire allouĂ©e mais pas encore utilisĂ©e peut ĂȘtre virtuellement allouĂ©e Ă  plusieurs processus (noyau Linux).

Les programmes dans l’espace utilisateur disposent de pouvoirs restreints sur la mĂ©moire : ils doivent demander au noyau de la mĂ©moire. Le noyau fait appel Ă  son gestionnaire de mĂ©moire pour allouer (ou non) la mĂ©moire au processus qui la demande. Si un processus tente d’utiliser des zones de mĂ©moire ne lui appartenant pas, il est Ă©vincĂ© automatiquement. Le mĂ©canisme d’éviction repose sur un mĂ©canisme du processeur, nommĂ©ment une unitĂ© de gestion de la mĂ©moire, ou MMU, qui signale au noyau l’existence d’un accĂšs fautif. C’est le noyau lui-mĂȘme qui prend la dĂ©cision de suspendre ou dĂ©truire immĂ©diatement le processus fautif.

Appels systĂšme

Les appels systĂšme sont des fonctions :

  • appelĂ©es depuis un programme de l’espace utilisateur ;
  • dont l’exĂ©cution (le traitement) est effectuĂ©e dans l’espace noyau ;
  • dont le retour est effectuĂ© dans le programme appelant dans l’espace utilisateur.

En plus d’un changement de mode d’exĂ©cution, l’appel systĂšme suppose au moins deux commutations de contextes :

  1. Contexte du programme appelant ;
    • changement de contexte ;
  2. Contexte du noyau ;
    • changement de contexte ;
  3. Contexte du programme appelant.

Le coĂ»t d’un appel systĂšme est nettement plus Ă©levĂ© qu’un simple appel de fonction intra-processus : alors qu’un appel de fonction ne suppose que quelques instructions primitives (chargement et exĂ©cution d’une zone mĂ©moire), le coĂ»t d’un appel systĂšme se compte en milliers ou dizaines de milliers d’instructions primitives, gĂ©nĂ©rant Ă  la fois une charge et des dĂ©lais d’exĂ©cution supplĂ©mentaires. Pour ces raisons, les fonctions qui sont utilisĂ©es de maniĂšre intense sont dĂ©placĂ©es dans l’espace noyau. Les programmes utilisateurs font alors un nombre restreint d’appels systĂšme de haut niveau. Les nombreuses interactions de bas niveau gĂ©nĂ©rĂ©es par ces appels systĂšme sont effectuĂ©es dans l’espace noyau. Cela concerne notamment les pilotes de pĂ©riphĂ©riques.

Les entrĂ©es/sorties font Ă©galement l’objet d’un traitement par l’ordonnanceur.

Gestion du matériel

La gestion du matĂ©riel se fait par l’intermĂ©diaire de pilotes de pĂ©riphĂ©riques. Les pilotes sont des petits logiciels lĂ©gers dĂ©diĂ©s Ă  un matĂ©riel donnĂ© qui permettent de faire communiquer ce matĂ©riel. En raison du trĂšs grand nombre d’accĂšs Ă  certains matĂ©riels (disques durs par exemple), certains pilotes sont trĂšs sollicitĂ©s. Ils sont gĂ©nĂ©ralement inclus dans l’espace noyau et communiquent avec l’espace utilisateur via les appels systĂšme.

En effet, comme cela a Ă©tĂ© vu dans le prĂ©cĂ©dent paragraphe, un appel systĂšme est coĂ»teux : il nĂ©cessite au moins deux changements de contexte. Afin de rĂ©duire le nombre des appels systĂšme effectuĂ©s pour accĂ©der Ă  un pĂ©riphĂ©rique, les interactions basiques avec le pĂ©riphĂ©rique sont faites dans l’espace noyau. Les programmes utilisent ces pĂ©riphĂ©riques au travers d’un nombre restreint d’appels systĂšme.

Cependant, indĂ©pendamment de l’architecture, de nombreux pĂ©riphĂ©riques lents (certains appareils photographiques numĂ©riques, outils sur liaison sĂ©rie, etc.) sont/peuvent ĂȘtre pilotĂ©s depuis l’espace utilisateur, le noyau intervenant au minimum.

Il existe des couches d’abstraction de matĂ©riel (HAL) qui prĂ©sentent la mĂȘme interface Ă  l’espace utilisateur et simplifient ainsi le travail des dĂ©veloppeurs d’applications. Dans les systĂšmes de type UNIX, l’abstraction utilisĂ©e est le systĂšme de fichiers : les primitives open, close, read et write sont prĂ©sentĂ©es Ă  l’espace utilisateur pour manipuler toutes sortes de pĂ©riphĂ©riques. On parle dans ce cas de systĂšme de fichiers synthĂ©tique.

Différents types de noyaux

Il existe toutes sortes de noyaux, plus ou moins spĂ©cialisĂ©s. Des noyaux spĂ©cifiques Ă  une architecture, souvent monotĂąches, d’autres gĂ©nĂ©ralistes et souvent multitĂąches et multiutilisateurs. L’ensemble de ces noyaux peut ĂȘtre divisĂ© en deux approches opposĂ©es d’architectures logicielles : les noyaux monolithiques et les micro-noyaux.

On considĂšre gĂ©nĂ©ralement les noyaux monolithiques, de conception ancienne, comme obsolĂštes car difficiles Ă  maintenir et moins « propres Â». Le noyau Linux Ă©tait dĂ©jĂ  qualifiĂ© d’obsolĂšte par Andrew Tanenbaum[6], dĂšs sa crĂ©ation en 1991. Il ne croyait pas, Ă  l’époque, pouvoir faire un noyau monolithique multiplate-forme et modulaire. La mise en place de micro-noyaux, qui consiste Ă  dĂ©placer l’essentiel des fonctions du noyau vers l’espace utilisateur, est trĂšs intĂ©ressante en thĂ©orie mais s’avĂšre difficile en pratique. Ainsi les performances du noyau Linux (monolithique) sont supĂ©rieures Ă  celles de ses concurrents (noyaux gĂ©nĂ©ralistes Ă  micro-noyaux), sans compter qu’il fut finalement portĂ© sur de trĂšs nombreuses plates-formes et qu’il est modulaire depuis 1995.

Pour ces raisons de performance, les systĂšmes gĂ©nĂ©ralistes basĂ©s sur une technologie Ă  micro-noyau, tels que Windows et Mac OS X, n’ont pas un « vrai Â» micro-noyau enrichi. Ils utilisent un micro-noyau hybride : certaines fonctionnalitĂ©s qui devraient exister sous forme de mini-serveurs se retrouvent intĂ©grĂ©es dans leur micro-noyau, utilisant le mĂȘme espace d’adressage. Pour Mac OS X, cela forme XNU : le noyau monolithique BSD fonctionne en tant que service de Mach et ce dernier inclut du code BSD dans son propre espace d’adressage afin de rĂ©duire les latences.

Ainsi, les deux approches d’architectures de noyaux, les micro-noyaux et les noyaux monolithiques, considĂ©rĂ©es comme diamĂ©tralement diffĂ©rentes en termes de conception, se rejoignent quasiment en pratique par les micro-noyaux hybrides et les noyaux monolithiques modulaires.

Noyaux monolithiques non modulaires

Architecture monolithique

Certains systĂšmes d’exploitation, comme d’anciennes versions de Linux, certains BSD ou certains vieux Unix ont un noyau monolithique. C’est-Ă -dire que l’ensemble des fonctions du systĂšme et des pilotes sont regroupĂ©s dans un seul bloc de code et un seul bloc binaire gĂ©nĂ©rĂ© Ă  la compilation.

De par la simplicitĂ© de leur concept mais Ă©galement de leur excellente vitesse d’exĂ©cution, les noyaux monolithiques ont Ă©tĂ© les premiers Ă  ĂȘtre dĂ©veloppĂ©s et mis en Ɠuvre. Cependant, au fur et Ă  mesure de leurs dĂ©veloppements, le code de ces noyaux monolithiques a augmentĂ© en taille et il s’est avĂ©rĂ© difficile de les maintenir. Le support par les architectures monolithiques des chargements Ă  chaud ou dynamiques implique une augmentation du nombre de pilotes matĂ©riels compilĂ©s dans le noyau, et par suite, une augmentation de la taille de l’empreinte mĂ©moire des noyaux. Celle-ci devint rapidement inacceptable. Les multiples dĂ©pendances crĂ©Ă©es entre les diffĂ©rentes fonctions du noyau empĂȘchaient la relecture et la comprĂ©hension du code. L’évolution du code s’est faite en parallĂšle Ă  l’évolution du matĂ©riel, et des problĂšmes de portage ont alors Ă©tĂ© mis en Ă©vidence sur les noyaux monolithiques.

En rĂ©alitĂ© les problĂšmes de la portabilitĂ© de code se sont rĂ©vĂ©lĂ©s avec le temps indĂ©pendants de la problĂ©matique de la technologie des noyaux. Pour preuve, NetBSD est un noyau monolithique et est portĂ© sur un trĂšs grand nombre d’architectures, alors que des noyaux tels que HURD ou celui de Windows XP utilisent des micro-noyaux censĂ©s faciliter le portage mais n’existent que pour quelques architectures.

Architecture d’un noyau monolithique

Noyaux monolithiques modulaires

Pour rĂ©pondre aux problĂšmes des noyaux monolithiques, ces derniers sont devenus modulaires. Dans ce type de noyau, seules les parties fondamentales du systĂšme sont regroupĂ©es dans un bloc de code unique (monolithique). Les autres fonctions, comme les pilotes matĂ©riels, sont regroupĂ©es en diffĂ©rents modules qui peuvent ĂȘtre sĂ©parĂ©s tant du point de vue du code que du point de vue binaire.

La trĂšs grande majoritĂ© des systĂšmes actuels utilise cette technologie : Linux, la plupart des BSD ou Solaris. Par exemple avec le noyau Linux, certaines parties peuvent ĂȘtre non compilĂ©es ou compilĂ©es en tant que modules chargeables directement dans le noyau. La modularitĂ© du noyau permet le chargement Ă  la demande de fonctionnalitĂ©s et augmente les possibilitĂ©s de configuration. Ainsi les systĂšmes de fichiers peuvent ĂȘtre chargĂ©s de maniĂšre indĂ©pendante, un pilote de pĂ©riphĂ©rique changĂ©, etc. Les distributions Linux, par exemple, tirent profit des modules chargeables lors de l’installation. L’ensemble des pilotes matĂ©riels sont compilĂ©s en tant que modules. Le noyau peut alors supporter l’immense variĂ©tĂ© de matĂ©riel trouvĂ© dans les compatibles PC. AprĂšs l’installation, lors du dĂ©marrage du systĂšme, seuls les pilotes correspondants au matĂ©riel effectivement prĂ©sent dans la machine sont chargĂ©s en mĂ©moire vive. La mĂ©moire est Ă©conomisĂ©e.

Les noyaux monolithiques modulaires conservent les principaux atouts des noyaux monolithiques purs dont ils sont issus. Ainsi, la facilitĂ© de conception et de dĂ©veloppement est globalement maintenue et la vitesse d’exĂ©cution reste excellente. L’utilisation de modules implique le dĂ©coupage du code source du noyau en blocs indĂ©pendants. Ces blocs amĂ©liorent l’organisation et la clartĂ© du code source et en facilitent Ă©galement la maintenance.

Les noyaux monolithiques modulaires conservent Ă©galement un important dĂ©faut des noyaux monolithiques purs : une erreur dans un module met en danger la stabilitĂ© de tout le systĂšme. Les tests et certifications de ces composants doivent ĂȘtre plus poussĂ©s.

D’un point de vue thĂ©orique, le grand nombre de lignes de code exĂ©cutĂ©es en mode noyau engendre des problĂšmes de portabilitĂ©. La pratique contredit largement la thĂ©orie et les noyaux modulaires sont aujourd’hui les plus portĂ©s.

SystĂšmes Ă  micro-noyaux

Architecture d’un systùme à micro-noyau

Les limitations des noyaux monolithiques ont amenĂ© Ă  une approche radicalement diffĂ©rente de la notion de noyau : les systĂšmes Ă  micro-noyaux.

Les systĂšmes Ă  micro-noyaux cherchent Ă  minimiser les fonctionnalitĂ©s dĂ©pendantes du noyau en plaçant la plus grande partie des services du systĂšme d’exploitation Ă  l’extĂ©rieur de ce noyau, c’est-Ă -dire dans l’espace utilisateur. Ces fonctionnalitĂ©s sont alors fournies par de petits serveurs indĂ©pendants possĂ©dant souvent leur propre espace d’adressage.

Un petit nombre de fonctions fondamentales est conservĂ© dans un noyau minimaliste appelĂ© « micro-noyau Â». L’ensemble des fonctionnalitĂ©s habituellement proposĂ©es par les noyaux monolithiques est alors assurĂ© par les services dĂ©placĂ©s en espace utilisateur et par ce micro-noyau. Cet ensemble logiciel est appelĂ© « micro-noyau enrichi Â».

Ce principe a de grands avantages thĂ©oriques : en Ă©loignant les services « Ă  risque Â» des parties critiques du systĂšme d’exploitation regroupĂ©es dans le noyau, il permet de gagner en robustesse et en fiabilitĂ©, tout en facilitant la maintenance et l’évolutivitĂ©. En revanche, les mĂ©canismes de communication (IPC) qui deviennent fondamentaux pour assurer le passage de messages entre les serveurs, sont trĂšs lourds et peuvent limiter les performances.

Avantages et inconvĂ©nients d’un systĂšme Ă  micro-noyau

Les avantages thĂ©oriques des systĂšmes Ă  micro-noyaux sont la consĂ©quence de l’utilisation du mode protĂ©gĂ© par les services qui accompagnent le micro-noyau. En effet, en plaçant les services dans l’espace utilisateur, ceux-ci bĂ©nĂ©ficient de la protection de la mĂ©moire. La stabilitĂ© de l’ensemble en est amĂ©liorĂ©e : une erreur d’un service en mode protĂ©gĂ© a peu de consĂ©quences sur la stabilitĂ© de l’ensemble de la machine.

De plus, en rĂ©duisant les possibilitĂ©s pour les services de pouvoir intervenir directement sur le matĂ©riel, la sĂ©curitĂ© du systĂšme est renforcĂ©e. Le systĂšme gagne Ă©galement en possibilitĂ©s de configuration. Ainsi, seuls les services utiles doivent ĂȘtre rĂ©ellement lancĂ©s au dĂ©marrage. Les interdĂ©pendances entre les diffĂ©rents serveurs sont faibles. L’ajout ou le retrait d’un service ne perturbe pas l’ensemble du systĂšme. La complexitĂ© de l’ensemble est rĂ©duite.

Le dĂ©veloppement d’un systĂšme Ă  micro-noyau se trouve Ă©galement simplifiĂ© en tirant parti Ă  la fois de la protection de la mĂ©moire et de la faible interdĂ©pendance entre les services. Les erreurs provoquĂ©es par les applications en mode utilisateur sont traitĂ©es plus simplement que dans le mode noyau et ne mettent pas en pĂ©ril la stabilitĂ© globale du systĂšme. L’intervention sur une fonctionnalitĂ© dĂ©fectueuse consiste Ă  arrĂȘter l’ancien service puis Ă  lancer le nouveau, sans devoir redĂ©marrer toute la machine.

Les micro-noyaux ont un autre avantage : ils sont beaucoup plus compacts que les noyaux monolithiques. 6 millions de lignes de code pour le noyau Linux 2.6.0 contre en gĂ©nĂ©ral moins de 50 000 lignes pour les micro-noyaux. La maintenance du code exĂ©cutĂ© en mode noyau est donc simplifiĂ©e. Le nombre rĂ©duit de lignes de code peut augmenter la portabilitĂ© du systĂšme.

Les premiers micro-noyaux (comme Mach) n’ont pas tout de suite atteint ces avantages thĂ©oriques. L’utilisation de nombreux services dans l’espace utilisateur engendre les deux problĂšmes suivants :

  1. La plupart des services sont Ă  l’extĂ©rieur du noyau et gĂ©nĂšrent un trĂšs grand nombre d’appels systĂšme ;
  2. Les interfaces de communication entre les services (IPC) sont complexes et trop lourdes en temps de traitement.

Le grand nombre d’appels systĂšme et la communication sous-jacente sont un dĂ©faut inhĂ©rent Ă  la conception des micro-noyaux. Dans L4, il a Ă©tĂ© rĂ©solu en plaçant encore plus de services en espace utilisateur. La rapiditĂ© de traitement des IPC a pu ĂȘtre amĂ©liorĂ©e en simplifiant les communications au maximum, par exemple en supprimant toute vĂ©rification des permissions, laissant ce soin aux serveurs externes.

Ces modifications radicales ont permis d’obtenir de bonnes performances mais elles ne doivent pas faire oublier qu’un micro-noyau doit ĂȘtre accompagnĂ© d’un grand nombre de services pour fournir des fonctionnalitĂ©s Ă©quivalentes Ă  celles des noyaux monolithiques. De plus, la grande libertĂ© dont disposent les services au niveau de la sĂ©curitĂ© et de la gestion de la mĂ©moire accroĂźt la difficultĂ© et le temps de leur dĂ©veloppement (ils doivent fournir leurs propres interfaces).

Architecture d’un micro-noyau enrichi par des services (micro-noyau enrichi)

Exemple d’associations micro-noyaux - noyaux enrichis - systùme d’exploitation

Micro-noyau Micro-noyau enrichi SystĂšmes d’exploitation associĂ©s
L4 HURD GNU/HURD
Mach (GNU Mach) HURD GNU/HURD
Mach XNU Darwin
Mach XNU Mac OS X

Noyaux hybrides

Architecture hybride
Architecture hybride : XNU

La dĂ©nomination de « noyaux hybrides Â» dĂ©signe principalement des noyaux qui reprennent des concepts Ă  la fois des noyaux monolithiques et des micro-noyaux, pour combiner les avantages des deux.

Lorsqu’au dĂ©but des annĂ©es 1990 les dĂ©veloppeurs et concepteurs se sont aperçus des faiblesses des premiers micro-noyaux, certains rĂ©intĂ©grĂšrent diverses fonctionnalitĂ©s non fondamentales dans le noyau, pour gagner en performance. Les micro-noyaux « purs Â» semblaient condamnĂ©s Ă  l’échec.

Alors que la philosophie gĂ©nĂ©rale des systĂšmes Ă  micro-noyaux est maintenue (seules les fonctions fondamentales sont dans l’espace noyau), certaines fonctions non critiques, mais trĂšs gĂ©nĂ©ratrices d’appels systĂšme, sont rĂ©intĂ©grĂ©es dans l’espace noyau. Ce compromis permet d’amĂ©liorer considĂ©rablement les performances en conservant de nombreuses propriĂ©tĂ©s des systĂšmes Ă  micro-noyaux. Un exemple de ce type de noyau hybride est le noyau XNU de Mac OS X. Il est basĂ© sur le micro-noyau Mach 3.0 mais qui inclut du code du noyau monolithique BSD au sein de l’espace noyau.

Cette dĂ©nomination est Ă©galement utilisĂ©e pour dĂ©signer d’autres types de noyaux, notamment les noyaux monolithiques sur micro-noyaux (temps rĂ©el ou non) tels que L4Linux (Linux sur L4), MkLinux (le noyau Linux sur Mach), Adeos, RTLinux et RTAI.

Plus rarement, on peut rencontrer le terme « noyau hybride Â» pour remplacer improprement « noyau monolithique modulaire Â» ou « micro-noyau enrichi Â».

Exo-noyaux

Étymologiquement, 'exo' signifie en grec 'hors de'. Un exo-noyau est donc un systĂšme d'exploitation fonctionnant en espace utilisateur (en 'user-space', au lieu du 'kernel-space' dans le cas des autres noyaux). Les fonctions et services du systĂšme d'exploitation sont assurĂ©s par de petits modules qui, selon les approches techniques, sont des librairies dynamiques (MIT, LibOSes) ou des dĂ©mons (IntraServices).

MĂ©ta-noyaux

Un « mĂ©ta-noyau Â» est un ensemble de logiciels qui vise Ă  appliquer la notion de noyau informatique au niveau d’un rĂ©seau informatique, en crĂ©ant une unique couche de gestion des pĂ©riphĂ©riques au niveau d’un rĂ©seau.

De cette maniĂšre, les logiciels peuvent ĂȘtre dĂ©ployĂ©s et utilisĂ©s sur le rĂ©seau informatique comme s’il s’agissait d’une machine unique, et l’ensemble des logiciels fonctionnant sur cette plate-forme peuvent se partager les ressources de maniĂšre intĂ©grĂ©e, comme elle le ferait sur un noyau simple.

Un mĂ©ta systĂšme doit Ă©galement permettre la personnalisation, la gestion des permissions ainsi que l’utilisation d’informations dĂ©pendant de la localisation.

Cette notion rejoint les notions de grappe de calcul, de machine virtuelle, de serveur d’application et de CORBA.

Noyaux temps réel

Une possibilitĂ© d’architecture de noyau temps rĂ©el hybride

Les noyaux temps rĂ©el sont fonctionnellement spĂ©cialisĂ©s. Ce sont des noyaux gĂ©nĂ©ralement assez lĂ©gers qui ont pour fonction de base stricte de garantir les temps d’exĂ©cution des tĂąches. Il n’y a pas Ă  proprement parler de notion de rapiditĂ© de traitement ou de rĂ©activitĂ© dans les noyaux temps rĂ©el, cette notion est plutĂŽt implicite Ă  la garantie des temps d’exĂ©cution en comparaison aux critĂšres temporels de l’application industrielle (la rĂ©activitĂ© d’un systĂšme de freinage ABS n’a pas les mĂȘmes critĂšres temporels que le remplissage d’une cuve de pĂ©trole).

TrĂšs utilisĂ©s dans le monde de l’électronique embarquĂ©e, ils sont conçus pour tourner sur des plates-formes matĂ©rielles limitĂ©es en taille, puissance ou autonomie.

Les noyaux temps rĂ©el peuvent adopter en thĂ©orie n’importe quelle architecture prĂ©cĂ©demment listĂ©e. Ils fournissent souvent deux interfaces sĂ©parĂ©es, l’une spĂ©cialisĂ©e dans le temps rĂ©el et l’autre gĂ©nĂ©rique. Les applications temps rĂ©el font alors appel Ă  la partie temps rĂ©el du noyau.

Une des architectures souvent retenue est un noyau hybride qui s’appuie sur la combinaison d’un micro-noyau temps rĂ©el spĂ©cialisĂ©, allouant du temps d’exĂ©cution Ă  un noyau de systĂšme d’exploitation non spĂ©cialisĂ©. Le systĂšme d’exploitation non spĂ©cialisĂ© fonctionne en tant que service du micro-noyau temps rĂ©el. Cette solution permet d’assurer le fonctionnement temps rĂ©el des applications, tout en maintenant la compatibilitĂ© avec des environnements prĂ©existants.

Par exemple, on peut avoir un micro-noyau temps rĂ©el allouant des ressources Ă  un noyau non temps rĂ©el tel que Linux (RTLinux, RTAI) ou Windows. L’environnement GNU (resp. Windows) peut alors ĂȘtre exĂ©cutĂ© Ă  l’identique sur le noyau pour lequel il a Ă©tĂ© conçu, alors que les applications temps rĂ©el peuvent faire directement appel au micro-noyau temps rĂ©el pour garantir leurs dĂ©lais d’exĂ©cutions.

VxWorks est un noyau propriĂ©taire temps rĂ©el trĂšs implantĂ© dans l’industrie bien que les systĂšmes Ă  base de noyau Linux se dĂ©ploient Ă©normĂ©ment et aient un succĂšs grandissant via RTAI (RTLinux Ă©tant brevetĂ©).

SynthĂšse des principaux noyaux et de leurs architectures

Noyau Noyau monolithique Noyau monolithique modulaire Micro-noyau Micro-noyau enrichi Noyau hybride Temps rĂ©el Exemples de systĂšmes d’exploitation associĂ©s
AIX Yes check.svg Oui Non Non Yes check.svg Oui AIX
Amoeba Yes check.svg Oui Yes check.svg Oui
BeOS Yes check.svg Oui Yes check.svg Oui Yes check.svg Oui BeOS
Anciens BSD Yes check.svg Oui Non Non Non Non BSD
BSD 4.4 Yes check.svg Oui Non Non Non Non BSD - Solaris 1
Chorus Yes check.svg Oui Yes check.svg Oui
Fiasco Yes check.svg Oui Yes check.svg Oui GNU/L4Linux/Fiasco
HURD Yes check.svg Oui Non Non Non Non GNU/HURD
Irix Yes check.svg Oui Non Non Yes check.svg Oui Irix
Jaluna Yes check.svg Oui Yes check.svg Oui Yes check.svg Oui Jaluna/Chorus
L4 Yes check.svg Oui Yes check.svg Oui GNU/HURD ; GNU/L4linux
Linux < 1.2 Yes check.svg Oui Non Non Non Non GNU/Linux
Linux > 1.2 Yes check.svg Oui Non Non Non Non GNU/Linux
LynuxWorks Yes check.svg Oui Yes check.svg Oui Yes check.svg Oui GNU/Linux/LynuxWorks
Mach Yes check.svg Oui Yes check.svg Oui Mac OS X, Darwin, GNU/HURD, GNU/Mklinux
Minix Yes check.svg Oui Non Non Yes check.svg Oui (Extensions) Minix
NeXTStep Yes check.svg Oui Yes check.svg Oui Non Non NeXTStep
Nucleus Yes check.svg Oui Yes check.svg Oui Yes check.svg Oui Nucleus
OS/2 Yes check.svg Oui Non Non Non Non OS/2
OS/360 Yes check.svg Oui Non Non Non Non OS/360
QNX Yes check.svg Oui Yes check.svg Oui Yes check.svg Oui QNX
RTAI Yes check.svg Oui Yes check.svg Oui Yes check.svg Oui GNU/RTAI
RT-OS360/75 Yes check.svg Oui Non Non Yes check.svg Oui IBM RTOS
Unix SysVr4 / SunOS 5 Yes check.svg Oui Non Non Non Non Solaris 7 et suivant
VxWorks Yes check.svg Oui Yes check.svg Oui Yes check.svg Oui Windows/VxWorks, BSD/VxWorks
Windows NT (Noyau de) Yes check.svg Oui Yes check.svg Oui Non Non Windows NT
XNU Yes check.svg Oui Yes check.svg Oui Yes check.svg Oui Mac OS X, Darwin
Microware OS-9 Yes check.svg Oui OS-9

Voir aussi

Articles connexes

Bibliographie

  • Andrew Tanenbaum, SystĂšmes d’exploitation, Pearson Education France, 2003, 2e Ă©d. (ISBN 2-7440-7002-5) ;
  • Daniel P. Bovet, Marco Cesati, Le Noyau Linux, O’Reilly, aoĂ»t 2006, 3e Ă©d. (ISBN 2-84177-243-8) ;
  • (en) David A. Peterson, Nitin Indurkhya, Patterson, Computer Organization and Design, Morgan Koffman (ISBN 1-55860-428-6) ;
  • (en) James L. Peterson, Abraham Silberschatz, Peter B. Galvin (dir.), Operating system concepts, Addison-Wesley, 1990 (ISBN 0-201-51379-X) ;
  • (en) B.S. Chalk, Computer Organisation and Architecture, Macmillan P. (ISBN 0-333-64551-0).
  • Laurent Bloch, Les systĂšmes d’exploitation des ordinateurs : histoire, fonctionnement, enjeux, Vuibert, 2003 (ISBN 2-7117-5322-0)

Liens externes

Notes et références

  1. ↑ Diverses raisons empĂȘchent l’utilisation par le noyau des mĂ©canismes d’abstraction qu’il fournit. Entre autres causes, la gestion des interruptions, l’espace d’adressage et la non rĂ©entrance.
  2. ↑ Voir Andrew Tanenbaum, Operating Systems: Design and Implementation, Prentice Hall,, 3rd ed. (ISBN 0-13-142938-8), chapitre 1,3 - 1,4 - 4.
  3. ↑ Le concept de mĂ©moire virtuelle date des annĂ©es 1960. La gĂ©nĂ©ralisation de cette technologie au grand public commence avec Windows XP et Mac OS X.
  4. ↑ L’implĂ©mentation de l’ensemble de ces propriĂ©tĂ©s par le gestionnaire de mĂ©moire du noyau suppose l’utilisation de microprocesseurs adaptĂ©s et Ă©quipĂ©s d’une unitĂ© de gestion de la mĂ©moire. (Gestionnaire de mĂ©moire matĂ©riel).
  5. ↑ Sur la plupart des noyaux, seule une fraction des capacitĂ©s thĂ©oriques de la machine peut ĂȘtre allouĂ©e Ă  un processus. Ainsi avec Linux sur x86 (32 bits), seuls les 3 premiers gigaoctets sont disponibles par dĂ©faut pour les processus [1].
  6. ↑ (en)Linux vs. Tanenbaum
  • Portail de l’informatique Portail de l’informatique
Goldenwiki 2.png
La version du 12 mars 2006 de cet article a Ă©tĂ© reconnue comme « article de qualitĂ© Â» (comparer avec la version actuelle).
Pour toute information complĂ©mentaire, consulter sa page de discussion et le vote l’ayant promu.
Ce document provient de « Noyau de syst%C3%A8me d%27exploitation ».

Wikimedia Foundation. 2010.

Contenu soumis à la licence CC-BY-SA. Source : Article Noyau de systeme d'exploitation de Wikipédia en français (auteurs)

Regardez d'autres dictionnaires:

  • Noyau de systĂšme d'exploitation — Pour les articles homonymes, voir noyau. Un noyau de systĂšme d’exploitation, ou simplement noyau, ou kernel (de l anglais[1]), est la partie fondamentale de certains systĂšmes d’exploitation. Il gĂšre les ressources de l’ordinateur et permet aux… 
   WikipĂ©dia en Français

  • Systeme D'exploitation — SystĂšme d exploitation Pour les articles homonymes, voir SE et OS. systĂšme d exploitation et logiciels applicatifs Le 
   WikipĂ©dia en Français

  • Systeme d'exploitation — SystĂšme d exploitation Pour les articles homonymes, voir SE et OS. systĂšme d exploitation et logiciels applicatifs Le 
   WikipĂ©dia en Français

  • SystĂšme d’exploitation — SystĂšme d exploitation Pour les articles homonymes, voir SE et OS. systĂšme d exploitation et logiciels applicatifs Le 
   WikipĂ©dia en Français

  • Noyau d'un systĂšme d'exploitation — Noyau de systĂšme d exploitation Pour les articles homonymes, voir noyau. Un noyau de systĂšme d’exploitation (abrĂ©gĂ© noyau, ou kernel en anglais, de l allemand kern), est la partie fondamentale de certains systĂšmes d’exploitation. Il gĂšre les… 
   WikipĂ©dia en Français

  • SystĂšme d'exploitation — Pour les articles homonymes, voir SE et OS (homonymie). Le systĂšme d exploitation est un intermĂ©diaire entre les logiciels d application et le matĂ©riel. Le systĂšme d exploitation 
   WikipĂ©dia en Français

  • SystĂšme d'exploitation temps rĂ©el — ██████████0 % Traduction 
   WikipĂ©dia en Français

  • Systeme d'exploitation base sur la securite — SystĂšme d exploitation basĂ© sur la sĂ©curitĂ© Voici la liste alphabĂ©tique des systĂšmes d exploitation non seulement reconnus pour leur sĂ©curitĂ©, mais issus d un projet axĂ© sur le renforcement de la sĂ©curitĂ©. Les critĂšres sont dĂ©taillĂ©s et peuvent… 
   WikipĂ©dia en Français

  • SystĂšme d'exploitation pour carte Ă  puce — Les systĂšmes d exploitation pour carte Ă  puce aussi appelĂ©s COS[note 1] assurent fondamentalement les mĂȘmes fonctions que les autres systĂšmes d exploitation, mais dans un contexte matĂ©riel oĂč les limitations matĂ©rielles et les problĂ©matiques de… 
   WikipĂ©dia en Français

  • SystĂšme d'exploitation pour capteur en rĂ©seau — Les systĂšmes d’exploitation pour rĂ©seau de capteurs sans fil (notĂ©s Ă©galement WSN[note 1]) sont des interfaces informatiques spĂ©cifiques, destinĂ©es au fonctionnement de capteurs en rĂ©seau. Un capteur en rĂ©seau (aussi appelĂ© mote en anglais) est… 
   WikipĂ©dia en Français


Share the article and excerpts

Direct link

 Do a right-click on the link above
and select “Copy Link”

We are using cookies for the best presentation of our site. Continuing to use this site, you agree with this.