Systèmes d’Exploitations Avancés

Systèmes d’Exploitations Avancés Chapitre I : Introduction Amine DHRAIEF Mastère professionnel en Modélisation, Bases de Données et Intégration des Systèmes ESEN, Univ. Manouba ÉTUDE PRÉLÉMINAIRE La compilation avec Make 27/09/16 SEA 2 make make est un logiciel qui construit automatiquement des fichiers, souvent exécutables, ou des bibliothèques à partir d'éléments de base tels que du code source. Il utilise des fichiers appelés makefile (Makefile) qui spécifient comment construire les fichiers cibles. À la différence d'un simple script shell, make exécute les commandes seulement si elles sont nécessaires. Le but est d'arriver à un résultat (logiciel compilé ou installé, documentation créée, etc.) sans nécessairement refaire toutes les étapes. make est particulièrement utilisé sur les plateformes UNIX. 27/09/16 SEA 3 make make sert principalement à faciliter la compilation et l'édition de liens puisque dans ce processus le résultat final dépend d'opérations précédentes. Pour ce faire, make utilise un fichier de configuration appelé makefile qui porte souvent le nom de Makefile. Ce dernier décrit des cibles (qui sont souvent des fichiers, mais pas toujours), de quelles autres cibles elles dépendent, et par quelles actions (des commandes) y parvenir. make cherche dans le répertoire courant le makefile à utiliser. 27/09/16 SEA 4 make Un Makefile est un fichier constitué de plusieurs règles de la forme : cible: dependance commandes Chaque commande est précédée d'une tabulation. Lors de l'utilisation d'un tel fichier via la commande make la première règle rencontrée, ou la règle dont le nom est spécifié, est évaluée. L'évaluation d'une règle se fait en plusieurs étapes : Les dépendances sont analysées, si une dépendance est la cible d'une autre règle du Makefile, cette règle est à son tour évaluée. Lorsque l'ensemble des dépendances est analysé et si la cible ne correspond pas à un fichier existant ou si un fichier dépendance est plus récent que la régle, les différentes commandes sont exécutées. 27/09/16 SEA 5 Exemple hello.c #include #include void Hello(void) { printf("Hello World\n"); } 27/09/16 SEA 6 Exemple #### hello.h void Hello(void); 27/09/16 SEA 7 Exemple main.c #include #include #include "hello.h" int main(void) { Hello(); return EXIT_SUCCESS; } 27/09/16 SEA 8 Exemple Makefile hello: hello.o main.o gcc -o hello hello.o main.o hello.o: hello.c gcc -o hello.o -c hello.c -W -Wall -ansi -pedantic main.o: main.c hello.h gcc -o main.o -c main.c -W -Wall -ansi -pedantic 27/09/16 SEA 9 Exemple Nous cherchons à créer le fichier exécutable hello, la première dépendance (hello.o) est la cible d'une des règles de notre Makefile, nous évaluons donc cette règle. Comme aucune dépendance de hello.o n'est une règle, aucune autre règle n'est à évaluer pour compléter celle-ci. Deux cas se présentent ici : soit le fichier hello.c est plus récent que le fichier hello.o, la commande est alors exécutée et hello.o est construit, soit hello.o est plus récent que hello.c est la commande n'est pas exécutée. L’évaluation de la règle hello.o est terminée. Les autres dépendances de hello sont examinées de la même manière puis, si nécessaire, la commande de la règle hello est exécutée et hello est construit. 27/09/16 SEA 10 Exemple Plusieurs cas ne sont pas gérés dans l'exemple précédent : Un tel Makefile ne permet pas de générer plusieurs exécutables distincts. Les fichiers intermédiaires restent sur le disque dur même lors de la mise en production. Il n'est pas possible de forcer la regénération intégrale du projet Ces différents cas conduisent à l'écriture de règles complémentaires : all : généralement la première du fichier, elle regroupe dans ces dépendances l'ensemble des exécutables à produire. clean : elle permet de supprimer tout les fichiers intermédiaires. mrproper : elle supprime tout ce qui peut être régénéré et permet une reconstruction complète du projet. En ajoutant ces règles complémentaires, notre Makefile devient donc : 27/09/16 SEA 11 Makefile Exemple all: hello hello: hello.o main.o gcc -o hello hello.o main.o hello.o: hello.c gcc -o hello.o -c hello.c -W -Wall -ansi -pedantic main.o: main.c hello.h gcc -o main.o -c main.c -W -Wall -ansi -pedantic clean: rm -rf *.o mrproper: clean rm -rf hello 27/09/16 SEA 12 Exemple Il est possible de définir des variables dans un Makefile, ce qui rend les évolutions bien plus simples et plus rapides, en effet plus besoin de changer l'ensemble des règles si le compilateur change, seule la variable correspondante est à modifier. Une variable se déclare sous la forme NOM=VALEUR et se voir utiliser via $(NOM). Nous allons donc définir quatre variables dans notre Makefile : Une désignant le compilateur utilisée nommée CC (une telle variable est typiquement nommé CC pour un compilateur C, CXX pour un compilateur C++). CFLAGS regroupant les options de compilation (Généralement cette variable est nommées CFLAGS pour une compilation en C, CXXFLAGS pour le C++). LDFLAGS regroupant les options de l'édition de liens. EXEC contenant le nom des exécutables à générer. 27/09/16 SEA 13 Exemple CC=gcc CFLAGS=-W -Wall -ansi -pedantic LDFLAGS= EXEC=hello all: $(EXEC) hello: hello.o main.o $(CC) -o hello hello.o main.o $(LDFLAGS) hello.o: hello.c $(CC) -o hello.o -c hello.c $(CFLAGS) main.o: main.c hello.h $(CC) -o main.o -c main.c $(CFLAGS) clean: rm -rf *.o mrproper: clean 27/09/16 SEA 14 rm -rf $(EXEC) Exemple ##### -W -Wall : Valider les avertissements (warnings) décrits en arguments. Il en existe une multitude. mais l'option la plus couramment utilisée est -Wall, pour activer tous les avertissements. ##### - pedantic : Le compilateur fournit des avertissements encore plus rigoureux qu'avec -Wall, principalement orientés sur la portabilité du code ##### -ansi : Compatible avec la norme C Ansi 27/09/16 SEA 15 Exemple ###### Pour compiler le projet $make ###### Pour supprimer tout les fichiers intermédiaires. $make clean ###### Pour supprimer tout ce qui peut être régénéré et permet une reconstruction complète du projet. $make mrproper 27/09/16 SEA 16 Rappel de concepts de bases 27/09/16 SEA 17 Contexte Le hardware CPU + Mémoires + périphériques d'E/S Ressources du système Le applicatifs Compilateur/navigateurs/Jeux/… Utilisent les ressources du système pour satisfaire les besoins des utilisateurs L'OS Contrôle le hardware et cordonne son utilisation par les différent applicatifs des utilisateurs. 27/09/16 SEA 18 L'OS de point de vue de l'utilisateur La plupart des utilisateurs utilisent des équipements mono-utilisateur Les ressources sont monopolisé par un seul utilisateur L'objectif de l'OS est d'optimiser la facilité de l'utilisation de l’équipement Peu d'attention est donnée aux performances du système L'OS ne cherche pas à optimiser l'utilisation/partage des ressources → des OS optimisés pour un seul utilisateur 27/09/16 SEA 19 L'OS de point de vue de l'utilisateur ###### Dans l'industrie et la recherche, un utilisateur utilise un terminal pour accéder à des serveurs/mainframes/calcuateurs... Au même moment d'autres utilisateurs accèdent à ces équipements via d'autres terminaux. Les utilisateurs partagent les ressources disponibles et peuvent s'échanger des messages. → L'objectif de l'OS est le partage équitable des ressources (CPU/Mémoire/…) entre les utilisateurs 27/09/16 SEA 20 L'OS de point de vue de système ###### L'OS est vue comme un dispatcher de ressources Temps CPU Espace mémoire Périphériques d'E/S ###### Gère les requêtes et les conflits des différent programmes/utilisateurs qui demandent l'accès à ces ressources. 27/09/16 SEA 21 Est-ce qu'il y a une définition d'un OS ? Le terme « système d'exploitation » couvre un grand nombre de fonctionnalités Une grande diversité d'architecture d'équipement ayant besoin d'un OS (des supercalculateurs au smartphones) Loi de Moore : nombre de transistor dans un µ- processor double tous les 18 mois → puissance des équipements en constante augmentations → émergence de nouvelles fonctionnalités/besoins 27/09/16 SEA 22 Est-ce qu'il y a une définition d'un OS ? Non : il n'y a pas une définition consensuelle Selon Prof. Avi Silberschatz (Professor of Computer Science at Yale University) : « we have no completely adequate definition of an operating system » Est-ce qu'on connaît exactement quels sont les composants fondamentales d'un OS ? Non « we have no universally accepted definition of what is part of the operating system » Une vision simpliste : « the operating system is the one program running at all times on the computer » 27/09/16 SEA 23 Quels sont les constituants d'un OS ? Procès antitrust contre Microsoft (justice américaine): windows offre des fonctionnalité ne faisant pas partie d'un OS (Internet Explorer) → concurrence déloyale La vente couplée de Windows et d'Internet Explorer a eu pour effet de laminer la concurrence, et particulièrement Netscape. Les OS des smartphone inclus en plus du kernel un middelware (iOS/Android) Des APIs pour les developpers 27/09/16 SEA 24 Finalité des OS ##### Un OS fournit l'environnement nécessaire pour que les programme puissent s’exécuter. ##### Pour cela, l'OS : Alloue les ressources matérielles et logicielles pour satisfaire les besoins des programmes. Présente aux programme une interface mieux adaptée à leurs besoins que celle fournie directement par le matériel. 27/09/16 SEA 25 Le système d'exploitation en tant que Le système d'exploitation en tant que machine virtuelle Hardware API Applicatio ns interface de programmation d'application) 27/09/16 SEA 27 Le système d'exploitation en tant que machine virtuelle Prise en charge par Linux: /kernels/linux 2.6/drivers/block/hd.c /* * This struct defines the HD's and their types. */ struct hd i struct { unsigned int head, sect, cyl, wpcom, lzone, ctl; int unit; int recalibrate; int special op; _}; Les champs représentent les caractéristiques géométriques du lecteur : i. le nombre de têtes (autrement dit de pistes), ii. le nombre de secteurs par piste, iii. le nombre de cylindres, 27/09/16 SEA 28 Le système d'exploitation en tant que Un disque est composé de cylindres, qui contiennent chacun autant de pistes qu'il y a de têtes placées verticalement. Les pistes se divisent en secteurs, le nombre de secteurs étant compris entre 8 et 32. Tous les secteurs contiennent le même nombre d'octets. Le système d'exploitation en tant que machine virtuelle La plupart des programmeurs ne veulent pas se soucier de la programmation des disques durs. Ils veulent une abstraction simple de haut niveau : considérer par exemple que le disque contient des fichiers nommés ; chaque fichier peut être ouvert en lecture ou en écriture ; il sera lu ou écrit, et finalement fermé. La partie machine virtuelle des systèmes d'exploitation soustrait le matériel au regard du programmeur offre une vue simple et agréable de fichiers nommés qui peuvent être lus et écrits 27/09/16 SEA 30 Le système d'exploitation en tant que machine virtuelle Machine virtuelle Cacher les Cacher les détails limitations de mise en œuvre physiques (taille du matériel mémoire) Col2 Cacher les détails de mise en œuvre du matériel Cacher les limitations physiques (taille mémoire) 27/09/16 SEA 31 Le système d'exploitation en tant que gestionnaire de ressources Les ordinateurs modernes se composent de processeurs, de mémoires, d'horloges, de disques, de moniteurs, d'interfaces réseau, d'imprimantes, et d'autres périphériques qui peuvent être utilisés par plusieurs utilisateurs en même temps. Le travail du système d'exploitation consiste à ordonner et contrôler l'allocation des processeurs, des mémoires et des périphériques entre les différents programmes qui y font appel. 27/09/16 SEA 32 Le système d'exploitation en tant que gestionnaire de ressources Imaginez ce qui se produirait si trois programmes qui s'exécutent sur un ordinateur essayaient simultanément d'imprimer leurs résultats sur la même imprimante. Les premières lignes imprimées pourraient provenir du programme 1, les suivantes du programme 2, puis du programme 3 et ainsi de suite. Il en résulterait le désordre le plus total. Le système d'exploitation peut éviter ce chaos potentiel en transférant les résultats à imprimer dans un fichier tampon sur le disque. Lorsqu'une impression se termine, le système d'exploitation peut alors imprimer un des fichiers se trouvant dans le tampon. 27/09/16 SEA 33 Systèmes multi-tâches La plupart des systèmes d'exploitation modernes permettent l'exécution de plusieurs tâches à la fois un ordinateur peut, pendant qu'il exécute le programme d'un utilisateur, lire les données d'un disque ou afficher des résultats sur un terminal ou une imprimante. On parle de système d'exploitation multi-tâches ou multi-programmé dans ce cas. 27/09/16 SEA 34 Systèmes multi-tâches: les processus La notion fondamentale des systèmes d'exploitation multi-tâches est celle de processus. Un processus est une instance de programme en train de s'exécuter. Un processus est représenté par un programme (le code), mais également par ses données et par les paramètres indiquant où il en est, lui permettant ainsi de continuer s'il est interrompu (pile d'exécution, compteur ordinal...). → On parle de l'environnement du programme. 27/09/16 SEA 35 Systèmes multi-tâches: le temps partagé La plupart des systèmes d'exploitation multi-tâches sont implémentés sur un ordinateur ayant un seul micro-processeur. Celui-ci, à un instant donné, n'exécute réellement qu'un seul programme, mais le système peut le faire passer d'un programme à un autre Ceci donne aux utilisateurs l'impression que tous les programmes sont exécutés en même temps. 27/09/16 SEA 36 Systèmes multi-utilisateurs ###### Un système multi-utilisateurs est capable d'exécuter de façon (pseudo-) concurrente et indépendante des applications appartenant à plusieurs utilisateurs. Concurrente signifie que les applications peuvent être actives au même moment et se disputer l'accès à différentes ressources comme le processeur, la mémoire, les disques durs... Indépendante signifie que chaque application peut réaliser son travail sans se préoccuper de ce que font les applications des autres utilisateurs. 27/09/16 SEA 37 Systèmes multi-utilisateurs #### Un système multi-utilisateurs est nécessairement multi-tâches mais la réciproque est fausse : ###### le système d'exploitation MS-DOS est mono- utilisateur et mono-tâche ; ###### les systèmes MacOS 6.1 et Windows 3.1 sont mono-utilisateurs mais multi-tâches ; ###### Unix et Windows NT sont multiutilisateurs. 27/09/16 SEA 38 Systèmes multi-utilisateurs #### Comme pour les systèmes multi-tâches, la multi-utilisation est émulée en attribuant des laps de temps à chaque utilisateur. #### Naturellement, le fait de basculer d'une application à l'autre ralentit chacune d'entre elles et affecte le temps de réponse perçu par les utilisateurs. 27/09/16 SEA 39 Systèmes multi-utilisateurs Lorsqu'ils permettent la multi-utilisation, les systèmes d'exploitation doivent prévoir un certain nombre de mécanismes : Un mécanisme d'authentification permettant de vérifier l'identité de l'utilisateur ; Un mécanisme de protection contre les programmes utilisateur erronés, qui pourraient bloquer les autres applications en cours d'exécution sur le système, ou mal intentionnés, qui pourraient perturber ou espionner les activités des autres utilisateurs ; Un mécanisme de comptabilité pour limiter le volume des ressources allouées à chaque utilisateur. 27/09/16 SEA 40 Structure externe d'un système d'exploitation Le système d'exploitation comporte un certain nombre de routines (sous-programmes). Les plus importantes constituent le noyau (kernel). Il gère les ressources de l’ordinateur et permet aux différents composants — matériels et logiciels — de communiquer entre eux. Le noyau d'un système d'exploitation se compose de quatre parties principales : **le gestionnaire de tâches (ou des processus)/ordonnanceur,** **le gestionnaire de mémoire,** **le gestionnaire de fichiers** **et le gestionnaire de périphériques d'entrée-sortie.** 27/09/16 SEA 41 Ordonnanceur 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 Il 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. 27/09/16 SEA 42 Ordonnanceur Commutation de contexte Une commutation de contexte (context switch) consiste à sauvegarder l'état d'un processus pour restaurer à la place celui d'un autre dans le cadre de l'ordonnancement d'un système d'exploitation multitâche. La commutation de contexte invoque au moins trois étapes. Par exemple, en présumant que l'on veut commuter l'utilisation du processeur par le processus P1 vers le processus P2 : 1) Sauvegarder le contexte du processus P1 quelque part en mémoire (usuellement sur la pile de P1). 2) Retrouver le contexte de P2 en mémoire (usuellement sur la pile de P2). 3) Restaurer le contexte de P2 dans le processeur, la dernière étape de la restauration consistant à reprendre l'exécution de P2 à son point de dernière exécution. 27/09/16 SEA 43 Ordonnanceur 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 27/09/16 SEA 44 Ordonnanceur 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. 27/09/16 SEA 45 le 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. 27/09/16 SEA 46 le gestionnaire de mémoire 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) **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 : la **mémoire peut être étendue** jusqu’aux capacités théoriques de la machine ; 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). 27/09/16 SEA 47 Le gestionnaire de mémoire 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 : Contexte du **programme appelant** ; Contexte du **noyau** ; 27/09/16 SEA 49 Différents types de noyaux L’ensemble de ces noyaux peut être divisé en deux approches opposées d’architectures logicielles : les noyaux monolithiques 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, dès sa création en 1992. **Linus vs. Tanenbaum:** http://www.dina.dk/~abraham/Linus vs Tanenbaum.html Il ne croyait pas, à l’époque, pouvoir faire un noyau monolithique multi plate forme et modulaire. 27/09/16 SEA 50 Monolithe #### Un monolithe (du grec μόνος monos, « un seul » et λίθος lithos, « pierre ») est un bloc de pierre de grande dimension, constitué d'un seul élément. Noyaux monolithiques non modulaires 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 27/09/16 SEA 52 Noyaux monolithiques non modulaires 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 devient 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. 27/09/16 SEA 53 Les systèmes monolithiques IPC: Inter-Process Communication 27/09/16 SEA 54 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. 27/09/16 SEA 55 Noyaux monolithiques modulaires ###### 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. 27/09/16 SEA 56 Noyaux monolithiques modulaires 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. 27/09/16 SEA 57 Systèmes à micro-noyaux Les limitations des noyaux monolithiques ont amené à une approche radicalement différente de la notion de noyau : les système approche à 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. 27/09/16 SEA 58 Systèmes à micro-noyaux 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 ». 27/09/16 SEA 59 Systèmes à micro-noyaux 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. 27/09/16 SEA 60 Systèmes à micro-noyaux 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. 27/09/16 SEA 61 Systèmes à micro-noyaux Le système gagne également en possibilités de configuration. 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** . 27/09/16 SEA 62 Systèmes à micro-noyaux ###### 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. 27/09/16 SEA 63 Systèmes à micro-noyaux #### L’utilisation de nombreux services dans l’espace utilisateur engendre les deux problèmes suivants : ###### La plupart des services sont à l’extérieur du noyau et génèrent un très grand nombre d’appels système ; ###### Les interfaces de communication entre les services (IPC) sont complexes et trop lourdes en temps de traitement. 27/09/16 SEA 64 Noyaux hybrides 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. 27/09/16 SEA 65 Noyaux hybrides 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. 27/09/16 SEA 66 Noyaux temps réel 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. 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 . 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. 27/09/16 SEA 67 Noyaux temps réel 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 . 27/09/16 SEA 68 PLAN DU COURS, VOLUME HORAIRE SEMESTRIEL & EVALUATION 27/09/16 SEA 69 Plan du Cours Chapitre I: Introduction aux systèmes d’exploitation Principe de base d’un SE Structuration des SEs Chapitre II: Gestion des Processus et Threads Notion de ressource/processus/threads. - Parallélisme et concurrence dans les SE s - Commutation de contexte d’un processus - Programmation système sous Unix (+Programmation multithreadée) Chapitre III: Concurrence, synchronisation et communication des processus/threads –IPC Les mécanismes de synchronisation Verrous, sémaphores, moniteurs, passage par messages, les tubes Unix. 27/09/16 SEA 70 Plan du Cours Chapitre IV: Interblocage Notion d’interblocage Solutions à l’interblocage (détection/guérison, prévention, évitement) Chapitre V: Ordonnancement (gestion du processeur) Notion sur les files d’attentes Politiques d’ordonnancement et comportement des processus Chapitre VI: Gestion de la mémoire (physique + virtuelle) Concepts fondamentaux; allocation statique/dynamique; politiques d’allocation 27/09/16 SEA 71 The END 27/09/16 SEA 72