Architectures et paradigmes pour concevoir des systèmes d’exploitations

1. Architectures et paradigmes pour concevoir des systèmes d’exploitations Clefs pour la conception des systèmes d’exploitations, principales stratégies d’abstraction et paradigmes de mise en œuvre. Par Gilles Grimaud Université des Sciences et Technologies de Lille http://www.lifl.fr/~grimaud/Cours

2. Plan • Pourquoi parler d’architecture • Paradigme événementiel • Paradigme des flux • Architecture des micro-noyaux • Abstraction et machines virtuelles • Virtualisation du matériel

3. Architectures des systèmes • L’exemple du système de fichier Bibliothèque « de base »liée dans chaque application. Accès dédié à un fichier Liaison symbolique des fichiers Logiciel propre à chaque système d’exploitation… Organisation des blocs en fichiers Allocation des blocs Partage de secteurs d’un disque Standard partagé entre différents systèmes. Logiciel en ROM associé au matériel. Manipulation des secteurs d’un disque

4. Architectures des systèmes • L’exemple du système de fichier Interface Java des flux Accès h.n. C Interface JVM/OS Interface d’accès bas niveau Mémoiremappée liaison symbolique Mécanisme de gestion des flux Organisation des blocs en fichiers Tubes Sockets … Swap Allocation des blocs Autres allocateurs Partage de secteurs d’un disque Manipulation d’un disque

5. Architectures des systèmes Nature des problèmes de conception des systèmes d’exploitation : • Maintenir la cohérence entre les composants système  Génie Logiciel • Assurer une gestion asynchrone des matériels  Traitements sous IT, mécanismes Temps Réel • Prémunir les applications des défaillances matérielles  Technologies tels que Mécanismes Transactionnels • Allouer et Réserver les ressources matérielles •  gestion des étreintes fatales, disponibilité • Assurer la tolérance aux défaillances des applications  Sécurité Innocuité des applications

6. Systèmes événementiels Principes : • Définir les systèmes d’information en terme de réaction plutôt qu’en terme d’action. Une grandes partie des programmes d’un système d’exploitation sont conçus sur ce principe. Ils réagissent à des événements matériels (Interruptions : cartes réseaux, claviers, synchro-vidéo, etc.) La mise en œuvre de certaines applications si prête aussi : e.g. Interfaces graphiques.  Ne nécessite pas de système multi-tâche.

7. Systèmes événementiels-mise en œuvre- Problème : Saturation événementielle idle réseau idle disque réseau réseau Solution : Files d’événements process idle rsx idle dsk rsx rsx file rsx dsk dsk rsx dsk rsx rsx rsx dsk rsx rsx interrupt  Introduction de systèmes multi-tâches

8. Systèmes événementiels-mise en œuvre- Bénéfice des paradigmes événementiels sur la conception des applications : Canevas applicatif « On ne vous donne plus une liste de procédures du système que vous pouvez appeler pour concevoir votre application ; on vous donne une liste de procédures que le système appellera sur votre application en temps utiles. » Canevas Application Système

9. Systèmes à base de flux Principes : • Représentation des données à traiter sous forme de flux (e.g. sockets, fichiers, tubes, …) • Activités du système d’information : appliquer des transformations sur un flux de données entrantes pour produire un flux de données sortantes(e.g. les flux Unix : ps -aux | grep grimaud | sort ) Avantage de ces architectures : • Synchronisation implicite des différentes activités « par les données » • Autorégulation de la charge de calcul entre les différents procédés de transformation des flux

10. Systèmes à base de flux Les différentes activités sont exprimées par des processus différents. Chaque processus consomme des données dans un (ou plusieurs) flux entrant et génère des résultats dans un flux sortant. Pilotescarte réseau IP TCP Décodeur Mpeg File d’attenteMontées IP File d’attentesocket File d’attentesortie graphique Tamponcarte réseau File d’attenteentrées paquets IP

11. Systèmes à base de flux-mise en œuvre- Première stratégie : Chaque transformation est assurée par un processus distinct. Chaque processus puise ses données d’entrée dans un flux entrant et génère ses résultats dans un flux de données sortantes… Les flux assurent une synchronisation implicite entre les activités.

12. Systèmes à base de flux-mise en œuvre- implémentation événementielle des algorithmes de traitement de flux : Etat SlIP Etat IP Etat TCP Interruption SlIPReceiveByte(char c) IPReceiveByte(char c) TCPReceiveByte(int source, char c) 13 C0 12 … (13, …) C0 … 13 DB DC 12 … C0

13. Les architectures monolithiques Fournir un logiciel de base formant : « un tout cohérent et fiable » Espace utilisateur :application Application A … Interface + Sécurité contrôle d’accès Système d’exploitation Abstracteurs Espace système :Noyau du système Gestionnaires Matériel

14. Architecture des micro-noyaux «Small is beautiful» effort = c  (object size)1,5 [BRO75A] effort object size

15. Architecture des micro-noyaux-mise en oeuvre- Limiter les abstractions fournies par le noyau. Faciliter la réalisation de nouvelles abstractions à partir de celles fournies par le noyau. Application A Application B Espace utilisateur :applications ++ Abstracteur  Abstracteur  Interface + Sécurité contrôle d’accès Micro-noyau Gestionnaires Espace système :Micro-Noyau Matériel

16. Abstraction et machines virtuelles Objectifs : • Portabilité (binaire) du code • Universalité de la plateforme • Vérification de codes binaires  Idéal surcouche de micro-noyau Pratiques : • Indépendance des systèmes d’exploitation (sic!) • Surcouche de système monolithique voir : Surcouche d’applications type « navigateurs »  Support de code mobile java lisp Machine Virtuelle i86 ARM7

17. Abstraction et machines virtuelles • Les composants de base d’une VM Java : (i) Chargeur de code, (ii) interprète, (iii) Mémoire à Objets, (iv) Interface OS Espace applicatif Chargeur de code Interfacesystème Interprète / JITS MémoireObjet Application VM Java Autre Application Système d’exploitation

18. Virtualisation des ressources matérielles Objectifs : • Extensibilité des noyaux (pilotes) • Support Multi-systèmes • Tolérance aux pannes systèmes Principes : • Virtualisation des ressources matérielles • Multiplexage & Démultiplexage • Interception & isolation matérielle

19. VIT VIT VIT Multiplexage IT VA VA VA Démultiplexage A Virtualisation des ressources matérielles • Matériel Virtuel • Simuler le fonctionnement d’un matériel sur un autre matériel : • RAM dans un disque dur ; • Microprocesseur ARM sur Microprocesseur Intel ; • TLB R4000 sur MMU Intel ; • … • Fonctionnement Matériel muliplexé/démultiplexé • 1 paquet Ethernet entrant plusieurs systèmes pour le traiter • 1 mémoire vidéo par système plusieurs mémoires vidéo pour les systèmes • … • Interception et isolation des accès matériels • 1 disque = x secteurs  1 secteur ne peut appartenir à plusieurs systèmes en même temps…

20. Virtualisation des ressources -mise en œuvre- • Stratégie « Emulateur » (e.g. VMWare) AutreApplication Application 1 Application 2 … Système d’exploitation Disque Mémoirede travail Connexion réseau Processeur Emulateur Fonctionnement simulé sur une autre machine, dans une application. Système d’exploitation Disque Connexion réseau Mémoirede travail Processeur Fonctionnement réel supporté par des mécanismes électroniques.

21. Virtualisation des ressources -mise en œuvre- • Stratégie « Exo-noyau » (e.g. Aegis) Application 1 Application 2 Application’ 1 Application’ 2 Système d’exploitation A Système d’exploitation B Disque Disque Mémoirede travail Connexion réseau Mémoirede travail Connexion réseau Processeur Processeur Fonctionnement démultiplexé du matériel Fonctionnement démultiplexé du matériel Exo-noyau (multiplexage & isolation) Disque Connexion réseau Mémoirede travail Processeur Fonctionnement réel supporté par des mécanismes électroniques.