1 Structure des Systèmes Informatiques Chapitre 3 Beaucoup de choses dans ce chap. du manuel sont faciles à lire et ne je les discuterai pas en classe.

Présentation au sujet: "1 Structure des Systèmes Informatiques Chapitre 3 Beaucoup de choses dans ce chap. du manuel sont faciles à lire et ne je les discuterai pas en classe."— Transcription de la présentation:

1 1 Structure des Systèmes Informatiques Chapitre 3 Beaucoup de choses dans ce chap. du manuel sont faciles à lire et ne je les discuterai pas en classe (donc, pas matière d’examen). Nous reviendrons sur plusieurs de ces concepts. Section 3.8 sera discutée dans les sessions exercices. http://w3.uqo.ca/luigi/

2 Ch.32 Concepts importants du Chapitre 3 n Responsabilités et services d’un SE n Le noyau n Appels du système (system calls) n Communication entre processus u Messagerie et mémoire partagée n Structure à couches n Machines virtuelles

3 Ch.33 Gestion de processus et UCT n Un processus=tâche est un programme en exécution n Le SE est responsable pour: u création, terminaison des processus F chargement en mémoire, exécution (load, run …) u allocation de ressources aux processus F mémoire, périphériques u exécution des ops d’E/S u suspension, reprise des processus u synchronisation, communication entre processus n Le SE intervient pour chacun de ces besoins

4 Ch.34 Gestion de mémoire principale (RAM) n Le SE est responsable pour: u savoir quels processus utilisent quelles parties de la mémoire u allouer la mémoire quand elle est demandée si elle est disponible u libérer la mémoire quand un processus n’en a plus besoin u Parfois c’est le système d’exécution des langages de programmation qui gère la mémoire en détail (Ex.: Java)

5 Ch.35 Autres services importants n Protection de ressources n Comptabilité, p.ex. pour charger les usagers payants

6 Noyau (kernel) et appels de système Ch.36

7 7 Le noyau ( kernel ) du SE n La partie résidente (toujours en mém. principale) du SE est appelée Kernel = noyau n Les autres parties sont amenées en mém. principale au besoin n Kernel contient les fonctionnalités critiques du SE: elles doivent toujours être prêtes à l’utilisation u traitement d’interruptions u gestion de UCT u gestion mémoire principale u communication entre processus u etc., nous verrons n À part ça, quoi exactement mettre dans le kernel est une question pour les concepteurs des SE n Presque toutes les fonctionnalités discutées dans ce cours sont dans le kernel

8 Ch.38 Appels du système n L’interface entre un processus et le SE u directement disponibles dans un shell UNIX ou dans un command prompt MS-Windows u aussi dans les langages de programmation `bas niveau` (assembleur) u ils sont cachés dans les langages de haut niveau (C, Java...)

9 Ch.39 Appels de systèmes pour interpréter le commandes (Unix, Linux ou MS-Windows) En Unix, le command interpreter (shell) peut exécuter des programmes pour démarrer et charger différents processus en mémoire, exécutant des appels de système appropriés (fork, exec). Détails dans sessions exercices. Configuration de mémoire hypothétique

10 Ch.310 Deux modèles de communication entre processus par appels de système a)transfert de messages entre processus (message passing) - utilisant le service de messagerie offert par le noyau b) à travers mémoire partagée entre processus (shared memory)

11 Ch.311 Messagerie et mémoire partagée n Messagerie: u Les processus doivent établir une connexion entre processus  appels de système open connection, accept connection, close connection, read/send message F les processus s’envoient des messages utilisant des identificateurs de processus préalablement établis n Mémoire partagée u les processus doivent établir des zones de communication entre eux u les processus doivent mutuellement synchroniser leur accès a cette zone F Pour ceci, il font appel au SE (Chap. 7)

12 Ch.312 Programmes système (compilateur, assembleur, éditeur …) Pas partie du kernel, en augmentent la fonctionnalité. Voir discussion et exemples dans le manuel kernel

13 Ch.313 Partage de responsabilités entre programmes de systèmes et noyau n C’est une décision de conception de SE de décider quelles fonctionnalités doivent être implémentées dans le kernel, et quelles dans les programmes de système.

14 Concept de Microkernel: le plus petit possible (Linux, mais pas Windows) Ch.314 https://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27exploitation (consulté sept 2016)

15 Fonctionnalités qui doivent forcément être dans le noyau n Elles sont les fonctionnalités dont tout processus a besoin, inclus les processus du noyau! u traitement d’interruptions, inclus E/S u gestion de UCT u gestion mémoire principale u communication entre processus Ch.315

16 Structure à couches Ch.316

17 Ch.317 Structure à couches dans les SE modernes couches Un SE est divisé dans un certain nombre de couches, bâties les unes sur les autres u la couche la plus basse communique avec le matériel u la plus élevée est l’interface usagers n Les couches supérieures utilisent les fonctionnalités fournies par les niveaux inférieurs

18 Ch.318

19 Ch.319 Structure à couches, variations n opérations créées par une couche et rendues disponibles à la prochaine couche seulement (cachées aux autres couches) n opérations créées dans une couche pour plusieurs couches supérieures

20 Ch.320 Structure à couches, variations n Opérations qui contournent une couche u À éviter en principe, mais on le fait ….

21 Ch.321 L’autre possibilité serait la structure réseau n Plus difficile à gérer, à cause des nombreuses interfaces et relations possibles À couchesRéseau

22 Ch.322 Avantages, désavantages de suivre fidèlement une structure en couches n Avantages: u Chaque couche ne doit connaître que les fonctionnalités fournies par la couche sous-jacente u Chaque couche ajoute ses propres fonctionnalités u Les erreurs peuvent plus facilement être isolés dans une couche spécifique F Maison construite un étage à la fois… poser l’étage n seulement quand l’n-1 est solide n Désavantages: u Pas efficace car un appel des programmes usager à des ressources du matériel implique autant d’appels qu’il y a des couches intermédiaires n Excellent principe, pas toujours fidèlement suivi u Pour des raisons d’efficacité

23 Ch.323 Structure de système - Approche simple n MS-DOS (1982 ) - cherchait à obtenir une fonctionnalité maximale avec des ressources limitées u pas bien modularisé F manque de séparation claire entre couches u accès direct aux périphériques (écran, etc.) permis aux programmes d`application F manque de contrôles, vulnérabilité u malheureusement, il fut adapté à des fonctionnalités plus complexes... Systèmes très instables F DOS fut la première version de Windows et une grande partie de l’histoire de Windows a été un effort de dépasser les limitations de MS-DOS F Jusqu’à Windows NT  Windows XP F Enfin, des systèmes plus fiables

24 Ch.324 Couches du MS-DOS (premiers systèmes Microsoft)

25 Ch.325 Structure UNIX  LINUX (1970  1991 … ) n Multi-tâches, multi-usagers depuis le début n Distinction claire entre: u programmes du système u noyau F tout ce qu’il y a entre l’interface des appels de système et le matériel. n Plus modulaire et protégé que MS-DOS n Plus tard, évolution vers le concept de micro- kernel (Linux)

26 Ch.326 Structure UNIX: trois couches principales noyau

27 Autre figure pour Linux Ch.327 A. Rubini and J. Corbet. Linux Device Drivers. Sebastopol, CA: O'Reilly & Associates, 2d ed., 2001. Online version at http://www.oreilly.com/catalog/linuxdrive2/index.html.

28 Systèmes d’exécution de langages: couches entre le langage usagers et le SE n Chaque langage de programmation repose sur u Des compilateurs u Des ‘systèmes d’exécution’ (run-time systems) qui rendent possible l’exécution de programmes après compilation F P.ex. le système d’exécution Java se préoccupe de gérer la mémoire pour les programmes Java F Gérer les appels de sous-programmes ou méthodes, etc. n Les systèmes d’exécution ne sont pas partie du SE u Mais en utilisent les fonctionnalités, qui donc sont cachées aux usagers Ch.328

29 Java run-time system Ch.329 Java run-time system Code Java compilé Couches du SE

30 Machines Virtuelles Ch.330

31 Ch.331 Machines virtuelles: le problème et la solution n Comment permettre de rouler différents SE sur une seule machine physique? n Pas évident, car chaque SE demande accès direct au matériel n SOLUTION: Un programme qui crée une couche qui met à disposition plusieurs machines virtuelles n Chaque machine virtuelle se comporte comme une machine physique séparée n Sur chacune, nous pouvons rouler un SE différent

32 Ch.332 Machines Virtuelles n Virtuel en informatique dénote quelque chose qui n ’est pas réel, n’est pas du matériel: il est construit par le logiciel sur la base des ressources fournies par le matériel n Une machine virtuelle est une machine créée par des couche de logiciel n Elle peut avoir des caractéristiques identiques à la machine physique du système: u mêmes instructions, etc. n Ou elle peut ‘simuler’ une autre machine physique u p.ex.pour exécuter Microsoft sur Apple n Plusieurs machines virtuelles peuvent être créées sur une machine physique donnée!

33 Ch.333 (a)Une seule mach. réelle et un seul noyau (b) plus. mach. virtuelles et plus. noyaux

34 Ch.334 Fonctionnement typique n Le système VM laisse exécuter normalement les instructions non privilégiées u Mais les adresses des instructions doivent être modifiées pour les renvoyer à la zone de mémoire de la VM appropriée n Les appels au système sont exécutés par le système VM et les résultats sont passés à la machine virtuelle sur laquelle le processus exécute

35 Modification d’adresses n Dans l’UCT il y a un registre qui renvoie de fois en fois les adresses de chaque instruction de programme à la machine virtuelle pour laquelle l’UCT est en train d’exécuter Ch.335 OPREG ADR REGISTRE + VM1 VM2 De cette manière, un seul programme peut être exécuté par plus. machines virtuelles

36 Ch.336 Avantages n Plusieurs machines virtuelles peuvent être obtenues à partir d’une seule machine physique: u Des nouvelles machines virtuelles peuvent être créés sur requête d’usagers n Chaque machine virtuelle peut utiliser un SE différent n Utile à fins d’expérimentation: u Un nouveau SE ou une nouvelle application peuvent être développés sur une machine virtuelle sans affecter les autres n Protection complète, car les machines virtuelles sont isolées les unes des autres (théoriquement)

37 Ch.337 Architecture VMWare: ici le virtualisateur n’es pas directement sur le matériel, il est sur Linux

38 Ch.338 Implémentations n MAC, LINUX et autres permettent de rouler Windows sur leur plateforme n Ils doivent fournir à Windows un environnement que Windows reconnaît comme son environnement matériel usuel u Normalement, environnement INTEL n Pareillement, Windows peut supporter d’autres SE

39 Ch.339 Simulateur: un concept différent PC SUN Microsystems MAC OS Simul. Intel Windows Applications Apple MAC Applications Windows Dans le cas précédent, toutes les machines étaient basées sur le même matériel, les mêmes instructions Ici, les instructions Intel doivent être simulées une par une dans l’environnement Apple-MAC

40 Différence entre virtualisateur et simulateur n Un virtualisateur permet de rouler plusieurs SE différents (ou identiques) sur une seule machine physique u Mais toutes les SE se basent sur le même matériel, les mêmes instructions n Un simulateur permet de rouler programmes conçus pour matériels différents sur une seule machine physique u Différents ensembles d’instructions Ch.340

41 L’infonuagique (cloud computing) n Dans l’infonuagique l’usager utilise les services offerts par un ‘nuage’ d’ordinateurs à travers connexions internet u Au lieu d’utiliser simplement son propre ordi ou le serveur local n L’offre de puissance de calcul et stockage du nuage doit être élastique pour suivre les besoins des usagers u Plus ou moins de serveurs UCT selon la demande n La création et destruction dynamique d’ordis virtuels en est un des mécanismes Ch.341

42 Infonuagique Ch.342 Chaque ordi peut être subdivisé en ordis virtuels Pour une offre élastique de puissance de calcul et stockage Pour chaque usager séparément et selon la demande Trois ordis physiques mais possiblement plus que 3 ‘virtuels ’

43 Ch.343 Concepts importants du Chapitre 3 n Responsabilités et services d’un SE n Le noyau n Appels du système (system calls) n Communication entre processus u Messagerie et mémoire partagée n Structure à couches n Machines virtuelles

44 Ch.344 Par rapport au manuel… n Étudier sections 3.1 jusqu’à 3.7. n La section 3.8 n’a pas été discutée en classe mais elle contient des concepts importants concernant Java donc c’est une excellente idée de la lire n Les sections 3.9, 3.10, 3.11 ne sont pas sujet d’examen cependant il est utile de les lire.

45 Ch.345 Structure à couches dans le système THE (1968) n La structure à couches fut inventée dans le système THE (E.W. Dijkstra) qui avait les couches suivantes: programmes usagers gestion E/S pilotage console opérateur gestion mémoire et tampons gestion UCT matériel Interface usager

46 Différentes visions du nom: UNIX n Originairement, UNIX était un SE spécifique n Il est devenu plus tard un nom pour une famille de SE qui fournissent un certain type de fonctionnalité n Souvent, le nom UNIX est compris comme une simple interface de commandes: u Sont UNIX les systèmes qui fournissent les instructions shell et API de l’UNIX u La structure interne du système pourrait être très différente (c’est le cas dans QNX) Ch.346

47 POSIX n POSIX est le nom d'une famille de standards définie depuis 1988 par IEEE. u Résultat d'un projet de standardisation des API des logiciels destinés à fonctionner sur des variantes du systèmes d’exploitation UNIX. n POSIX = Portable Operating System Interface, u X exprime l'héritage UNIX de l'Interface de programmation n Essentiellement POSIX a cherché à normaliser l’interface typique des systèmes UNIX u Instructions shell, API Ch.347

48 QNX: Un succès dans notre région n QNX est un SE pour les applications temps-réel et les système embarqués u Il est essentiellement Unix u Offre l’interface POSIX n Développé dans la région (à Kanata) à partir de 1980 n A été utilisé dans un grand nombre d’applications temps-réel et embarquées, par un grand nombre de compagnies n La compagnie a été achetée par Research in Motion (RIM) qui utilise QNX dans ses produits u Playbook, BlackBerry, etc Ch.348

49 Note historique-théorique n Le concept d’ordinateur universel qui peut simuler n’importe quel ordinateur, inclus soi-même, fut conçu par Alan Turing dans les années 1930 u «La machine de Turing » u Bien avant les premiers ordinateurs électroniques u Ce concept est à la base du concept de machine virtuelle u Il est aussi à la base de nombreux concepts informatiques, pratiques et théoriques Ch.349

50 Questions pour révision 1 n Expliquer la différence: processus, processeur, programme n Que c’est que le noyau du SE? Expliquer la différence essentielle entre le noyau et autres composants du SE. n Expliquer pourquoi chacun des suivants doit être dans le noyau: u traitement d’interruptions u gestion de l’UCT u gestion mémoire principale u communication entre processus Ch.350

51 Questions pour révision 2 n Quelle est la relation entre appels du système et interruptions? n Quels sont les avantages et les désavantages de structurer un SE en couches plutôt que d’une autre manière, p.ex. en réseaux de composantes n Quelle est la différence entre systèmes d’exploitation et systèmes d’exécution de langages? n La gestion de la mémoire en Java, appartient-elle au SE ou au système d’exécution Java? Ch.351

52 Questions pour révision 3 n Quels sont les avantages principaux des machines virtuelles? n Quelle est la différence entre une machine virtuelle et un simulateur d’un autre matériel? n Décrire l’idée de base de l’infonuagique Ch.352