INFO502 : Systèmes d'exploitation

Ce wiki est un complément de cours pour le cours « info-502 : systèmes d'exploitation ». La participation au wiki est fortement encouragée.

Pour pouvoir modifier les pages, inscrivez-vous (lien en haut à droite) pour obtenir un login et mot de passe. (Choisissez un login du style PrenomNom...)

Je vous conseille d'aller lire ce guide pour vous familiariser avec les wikis.

Exercice : si vous n'en avez pas, créez-vous un compte et essayez de modifier cette page (correction de fautes d'hortographe, rajout de détails, mise en page, ...)

Vous pouvez aussi utiliser la page de discussion pour ... discuter. (Ou poser des questions, faire des commentaires etc.)

---

---

---

---

Introduction

-- ...

Repères historiques

Voici quelques évènements clés dans l'histoire des systèmes d'exploitation. Pour plus de détails, ou pour des compléments sur l'histoire de l'informatique, je vous renvoie sur Wikipedia : "History of operating systems" et "History of computing".

Les premiers ordinateurs ne comportaient pas vraiment de système d'exploitation : c'étaient des opérateurs humains qui géraient tout. (C'était juste après la seconde guerre mondiale, l faut savoir que les langages de programmation n'existaient même pas...) La petite histoire (??) raconte qu'à un moment, les processus pour l'ordinateur de l'université de Cambridge étaient accrochés sur une corde à linge et que c'était la couleur des pinces à linges qui donnait la priorité. (??)

Le passage à la notion de système d'exploitation c'est faite graduellement pour répondre à la complexité de plus en plus grande des ordinateurs et aux demandes des utilisateurs.

Les premier systèmes d'exploitation datent probablement de 1956. Ils permettaient simplement d'exécuter un nouveau programme lorsque le précédent était terminé. Les ordinateurs d'IBM de la famille System/360 ont ensuite eu toute une série de systèmes d'exploitation plus ou moins similaires : OS/360, DOS/360 (rien à voir avec MS-DOS), TSS/360... C'est à cette époque qu'est apparu la notion de multiprogrammation (possibilité d'avoir plusieurs processus entrelacés.) C'est également au début des années 60 qu'on a commencé à voir des systèmes avec temps partagé : plusieurs utilisateurs pouvaient utiliser un ordinateur. Le système Multics a été, à ce niveau comme à d'autres, assez révolutionnaire. Multics a été utilisé jusqu'en 2000 !

Multics n'était par contre pas approprié pour les mini-ordinateurs où le nombre d'utilisateur est relativement restreint. En 1969, Ken Thomson a développé une variante simplifié de Multix : Unix...

Ce n'est qu'un peu plus tard (1979) que la première version de DOS (86-DOS ou QDOS) apparaît. 86-DOS sera racheté par Microsoft un 1980...

Liens et compléments :

• Timeline of operating systems
• généalogie des systèmes Unix : Unix History
• généalogie de Windows : Windows History
• généalogie des systèmes non-Unix : timeline of non-Unix operating systems

Vue d'ensemble

Ce cours reste assez généraliste et essaie de regarder les principales fonction d'un système d'exploitation. Les systèmes de type Unix (Linux) sera un exemple privilégié. À cause de leur complexité intrinsèque, les évolutions modernes (architectures multicoeur ou multiprocesseur, ...) seront en partie ignorée dans un premier temps.

Les problèmes fins de communication entres processus ne seront que très peu abordés, car ils font l'objet d'un cours séparé (info604) pour la filière info.

Nous allons suivre l'ordre classique consistant à regarder :

1. les processus
2. la mémoire
3. les entrées / sorties

La fin du cours dépendra du temps restant...

Les processus

Un processus est simplement un programme « en exécution ». À tout instant, un ordinateur de bureau contemporain contient de nombreux processus qui doivent partager le (les) processeur(s) pour donner l'impression qu'ils s'exécutent « en même temps ». Un des rôles du système d'exploitation consiste à décider dans quel ordre les processus vont effectivement pouvoir utiliser le processus.

La mémoire

La mémoire est, comme le processeur, une ressource partagée par les différents processus. Il faut donc gérer la quantité de mémoire allouée et utilisée pour que les processus n'aient pas à s'occuper de ceci. Un des concepts fondamentaux est celui de mémoire virtuelle. Ceci permet d'offrir un espace mémoire pour chacun des processus de manière transparente.

Les entrées / sorties

Un ordinateur n'est pas (plus) un système indépendant du reste du monde : il interagit avec l'extérieur à travers des périphériques d'entrées/sorties (clavier / écran / souris / ...). La gestion de ces périphériques pose un ensemble de problèmes que nous aborderons brièvement...

...

Une fois ces notions vues, nous regarderons peut-être les problèmes de sécurité, de multimédia ou des architectures multiprocesseurs.

Préliminaires

Quoi ?

Les ordinateurs, ou plus simplement les microcontroleur sont des circuit électronique avec une puce « processeur ». Le développement d'applications n'est pas facile si on se place au niveau électronique et que l'on parle directement au CPU. Pour faciliter la vie des programmeurs, plusieurs couches d'abstraction sont nécessaires. La première se place au niveau matériel et s'occupe directement des problème électroniques ou de très bas niveau. Il s'agit du firmware. Il répond par exemple aux questions comme :

• qu'elle est l'amplitude des signaux envoyés par l'horloge ?
• est-ce que l'UC possède un pipeline ?
• ...

Un firmware est donc forcement très lié au matériel sur lequel il tourne.

La couche suivante est le système d'exploitation à proprement parler. Dans le cas que vous connaissez le mieux (ordinateur personnel), le système d'exploitation fournit une interface pour :

• exécuter un programme
• exécuter plusieurs programmes « en même temps »
• gérer les ressources (temps processeur, mémoire disponible, entrées / sorties)
• les opérations sur les fichiers
• offrir des garanties de sécurité

Où ?

On trouve des système d'exploitation partout :

• dans les ordinateurs personnels (Linux, BSD, MacOS, Solaris, Windows, ChromeOS (?))
• dans les PDA (PalmOS, ...)
• dans les téléphones portables (Android, OpenMoko,Symbian,)
• console de jeux
• lecteur MP3 (Rockbox, ...)
• les microcontroleurs « avancés »

Comment ?

Langage de programmation

Le système d'exploitation se situe entre le firmware (très bas niveau) et l'utilisateur. La nécessité d'accéder à ces ressources de très bas niveau implique que les langages de haut niveaux (Java, Ada, Python, ...) ne sont pas du tout adaptés à l'écriture des systèmes d'exploitation. Le langage le plus utilisé reste à ce jours le langage C : Linux, BSD, MacOS, Windows, ... sont tous écrits pour leur plus grande partie en C.

Vous avez normalement un cours de C en parallèle, et les TP utiliseront le langage C. (La référence sur le langage C reste à mon goût le livre de Kernighan et Ritchie : « the C Programming language ». (Disponible en francais à la BU sous le titre « Le langage C : norme Ansi ».) Il existe de nombreux autres livres / documents sur la programmation C comme le polycopié de Bernard Cassagne « introduction au langage C ».

Les premiers systèmes d'exploitation étaient écrits directement en langage machine, ou bien en langage d'assembleur ; et les systèmes actuels comportent encore quelques parties de très bas niveau en langage d'assemblage...

Notion d'appel système, norme POSIX

La programmation de haut niveau en C est assez différentes de la programmation système. De nombreuses fonctions C utilisent en fait des « appels système », c'est à dire des appels de fonctionnalités propres du système d'exploitation. Les appels système typiques sont :

• les fonctions relatives aux fichiers (création, suppression, modification...)
• les fonctions relatives à la gestion de la mémoire
• les fonctions relatives aux processus (fork)
• ...

De nombreux système d'exploitation proposent une interface POSIX (« Portable Operating System Interface for Unix »). Cette norme définit entre autres un ensemble de fonctions pour utiliser les appels systèmes. Le nombre de ces fonctions est relativement faible : une centaine ; et chacune correspond en gros à un appel système. Certaines de ces fonctions ne sont pas définies directement dans le système d'exploitation, mais dans des librairies. Pour Linux, il s'agit en général de la librairie Glibc (GNU C Library).

Par exemple, la fonction open (qui permet d'ouvrir un fichier) correspond exactement à un appel système ; alors que la fonction malloc (qui permet d'allouer dynamiquement de la mémoire dans le tas) peut générer plusieurs appels système (brk et sbrk).

Pour visualiser les appels systèmes effectués par un programme sous Linux, vous pouvez utilisez l'utilitaire strace ou ltrace. Par exemple, dans le shell :

 $ strace -e trace=file ls -l 2> trace

permet de récupérer tous les appels systèmes relatifs aux fichiers lors de l'appel à ls -l. La liste des appels système est redirigée dans le fichier trace qui contiendra par exemple des lignes telles que

lstat64("Desktop", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lgetxattr("Desktop", "security.selinux", 0x8cc08e0, 255) = -1 ENODATA (No data available)

dénotant ainsi un appel aux appels système lstat64 et lgetxattr...

Les principaux systèmes compatibles POSIX sont :

• Linux
• BSD (et variantes)
• Mac OS X
• Solaris

De nombreux appels systèmes sont disponibles directement (sans avoir besoin d'écrire un programme C) à travers le shell. Exécuté dans un terminal, le shell permet, en première approximation, de passer directement des commandes au système d'exploitation. (La norme POSIX définit également un ensemble de fonctions du shell. Il est donc relativement aisé de changer de système d'exploitation tant qu'on reste dans les systèmes compatibles POSIX.)

Windows d'un autre coté utilise l'interface Win32 API, qui définit plusieurs milliers de fonctions. La plupart de ces fonctions peuvent utiliser plusieurs appels système...

Les systèmes d'exploitation qui utilisent l'API Win32 sont :

• Windows, depuis Windows95.

Il est possible d'installer un environnement compatible POSIX sur une machine Windows grace à Cygwin. (C'est d'ailleurs fortement conseillé si vous ne voulez pas installer une version de Linux ou BSD sur votre ordinateur personnel...)

Mode noyau / mode utilisateur

La partie fondamentale du système d'exploitation est le noyau (kernel en anglais). C'est la couche de plus bas niveau.

Les fonctionnalités de très bas niveau offertes par le noyau peuvent facilement planter l'ordinateur. Il faut donc une politique de restriction pour que tous les programmes ne puissent y accéder dans leur totalité. On parle de

• mode noyau
• mode utilisateur

Dans le mode utilisateur, on ne peut accéder à ces fonctionnalités qu'a travers les appels systèmes ; dans le mode noyau, on peut tout faire... Bien entendu, un appel système doit passer momentanément passer en mode noyau pour pouvoir exécuter les commandes pertinentes, puis il repasse automatiquement en mode utilisateur.

La définition d'un appel système pourrait donc être « fonctionnalité atomique nécessitant un passage en mode noyau ».

Noyau, noyau monolithique, micro-noyau

La partie principale du système d'exploitation. C'est lui qui gère les ressources, les entrées / sorties, la communication entre processus, ... Les deux architectures principales pour un noyau sont :

• noyau monolithique
• micro-noyau

La plupart des systèmes actuels sont basés sur un noyau monolithique (Linux, BSD, Mac OS X, Solaris, Windows).

Les noyaux monolithiques sont parfois décrits comme « sans vraie structure » : une grosse soupe où cohabitent toutes les fonctionnalités du système d'exploitation. L'idée d'avoir un système unique qui gère tout est effectivement peu attirante et peux poser quelques problèmes de génie logiciel... Un noyau monolithique est donc la couche entre le matériel et les programmes utilisateurs. Pour éviter de compiler des noyaux énormes, les noyaux monolithiques actuels utilisent en plus la notion de module. Ce sont des morceaux du noyau qu'on peut charger ou décharger au besoin. Si l'interface est connue, ces modules peuvent éventuellement être en binaire, ce qui permet d'utiliser des modules propriétaires avec un noyau libre. Sous Linux, la commande

$ lsmod

permet d'obtenir la liste des modules chargés dans le noyau.

Les micro-noyaux d'un autre coté sont basés sur la remarque que seule une toute petite partie du noyau accède effectivement au matériel. Seule cette petite partie nécessite donc des privilèges et effectue des appels système. Le reste du système d'exploitation peut être programmé en mode utilisateur, « au dessus » de cette partie. Par exemple, le micro noyau offrira la possibilité de charger un nouveau processus, mais l'ordonnanceur (qui choisit quel processus devra être chargé) ne fera pas parti du micro-noyau. On parle parfois de services / serveurs au dessus du micro-noyau. Ceci permet d'avoir un noyau bas niveau beaucoup plus petit. Bien que ceci soit une bonne idée, et que les micro-noyaux puissent fournir de meilleurs garanties de sécurité, peu de noyaux sont effectivement des micro-noyaux. Un des problèmes est qu'un tels micro-noyau est un peu plus lent que ses cousins monolithiques. La raison principale est que dans le cas d'un micro-noyau, un appel système nécessite en fait des communications inter-processus. Andrew Tanenbaum est un fervent défenseur des micro-noyaux.

Une autre architecture possible est d'utiliser des couches successives, chacune avec des privilèges réduits. Le système Multics avait cette architecture. Par exemple, dans le système THE (1965), les couches étaient les suivantes :

1. noyau bas niveau, multiprogrammation
2. allocation de la mémoire pour les processus
3. IPC (communication inter processus)
4. entrées / sorties (buffer, etc.)
5. programmes utilisateurs (compilation, exécution, ...)
6. utilisateur (Dijkstra a annoté la description de cette couche par « not implemented by us »)

Une dernière catégorie de noyau est la catégorie des machine virtuelles. Ces noyaux sont un peu à part, car il s'agit d'émuler un système d'exploitation ou du matériel particulier à l'intérieur d'un autre système d'exploitation ou matériel. Le mode noyau de la machine virtuelle est en fait dans le mode utilisateur du noyau original...

Les processus

Aller hop commençons par une petite définition du type wikipédia :

Un processus (en anglais, process), en informatique, est défini par :

• un ensemble d'instructions à exécuter (un programme) ;
• un espace mémoire pour les données de travail ;
• éventuellement, d'autres ressources, comme des descripteurs de fichiers, des ports réseau, etc.

Un ordinateur équipé d'un système d'exploitation à temps partagé est capable d'exécuter plusieurs processus de façon « quasi- simultanée ». Par analogie avec les télécommunications, on nomme multiplexage ce procédé. S'il y a plusieurs processeurs, l'exécution des processus est distribuée de façon équitable sur ces processeurs.

Le processus doit être imaginé comme quelque chose qui prend du temps, donc qui a un début et (parfois) une fin. Un processus peut être démarré par un utilisateur par l'intermédiaire d'un périphérique ou bien par un autre processus (les applications des utilisateurs sont des processus).

Le système d'exploitation est chargé d'allouer les ressources (mémoires, temps processeur, entrées/sorties) nécessaires aux processus et d'assurer que le fonctionnement d'un processus n'interfère pas avec celui des autres (isolation).

Pas sûr d'avoir tout compris ? Ce n'est pas grave, essayons autrement.

• "Processus ? What's that ?"

Un processus est un programme en train de s’exécuter.

• "Et à quoi ça sert ?" peut-être te pose tu la question ?

Et bien ça sert à réaliser plusieurs activités en ~même temps~. Grâce à la gestion des processus on peut regarder un film (obtenu par des moyens tout à fait légaux cela va de soit), tout en jouant à la dame de pique. (et dire que certain(e)s affirment que l'homme est monotâche)

Une petite définition : Le processeur est le composant essentiel d'un ordinateur. C'est lui qui interprète les instructions et traite les données d'un programme.

Comment ça se passe alors quand je démarre une application? L'ordinateur à une tâche à accomplir, les instructions sont donc envoyées au processeur qui va se charger de tout ça. Par contre quand il à plusieurs choses à faire le travail se corse un peu. Il faut faire en sorte de partager le processeur entre les différentes tâches.

On en arrive donc à cette fameuse gestion des processus.

• On appelle simultanéité l'activation de plusieurs processus au même moment.

Si le nombre de processeurs est au moins égal au nombre de processus, on parle de simultanéité totale ou vraie, sinon de pseudo-simultanéité.

• pseudo-simultanéité : La plus-part du temps les ordinateurs n'ont qu'un seul processeur, c'est pourquoi la simultanéité n'est pas possible. Mais comme le temps d'exécution d'une instruction par le processeur est très court, de l'ordre de la nano-seconde, ce qui permet la réalisation de plusieurs centaines de millions d'instructions par seconde, et ainsi une tranche de temps de quelques fractions de seconde, partagée entre plusieurs processus, donne à l'échelle macroscopique l'illusion de la simultanéité.

En résumé : Un système d'exploitation doit la plupart du temps traiter plusieurs tâches en même temps, et comme il n'a, en général, qu'un seul processeur, il devra contourner ce problème grâce à un pseudo-parallélisme. Il traite une tâche à la fois, s'interrompt et passe à la suivante. La commutation de tâches étant très rapide, il donne l'illusion d'effectuer un traitement simultané.

On peut imaginer un SE dans lequel les processus pourraient être dans trois états :

• élu : en cours d'exécution. Un processus élu peut être arrêté, même s'il peut poursuivre son exécution, si le SE décide d'allouer le processeur à un autre processus.
• bloqué : il attend un événement extérieur pour pouvoir continuer (par exemple une ressource; lorsque la ressource est disponible, il passe à l'état "prêt").
• prêt : suspendu provisoirement pour permettre l'exécution d'un autre processus.

NB :

-Un processus est un programme en cours d'exécution

-Un programme lancé plusieurs fois donnera plusieurs processus

-Il y a beaucoup de processus en un instant donnée

-Les système d'exploitation gère le multiprocessus

---

---

Références

• le livre « Systèmes d'exploitation » de Andrew Tanenbaum est disponible à la BU
• la page du projet SOS
• la norme POSIX:2004
• l'API win32
• Commentary on the Sixth Edition UNIX Operating System