Structure d'un système d'exploitation
On peut aussi aborder les systèmes d'exploitation par leur organisation : leur structure.
Tannenbaum propose une classification en quatre catégories :
Systèmes monolithiques
Ce système est en fait un "non-système" : il consiste en un ensemble de procédures d'interfaces bien déterminées, qui peuvent s'appeler mutuellement, le "système d'exploitation" étant obtenu par la compilation et l'édition de lien de toutes ces procédures.
Parmi les inconvénients, cette structure implique que toutes les procédures, tous les objets sont visibles et accessibles partout.
Cela va à l'encontre de la tendance de construire des modules indépendants, dans lesquels la plupart des informations sont privées (locales), seuls les éléments strictement définis dans l'interface et les points d'entrée étant accessibles.
Même dans ce schéma, on peut avoir un minimum de structure : un utilisateur peut accéder à un service offert par le système d'exploitation au moyen d'un appel au système (system call), en plaçant les paramètres en des endroits définis à l'avance (pile, registres, etc.) puis en exécutant une instruction particulière appelée appel au noyau ou appel au superviseur (Supervisor Call ou en abrégé SVC) :
Cette instruction a pour effet de basculer la machine du mode utilisateur en mode superviseur, puis transfère le contrôle au système d'exploitation.
La plupart des CPU ont deux modes : le mode superviseur pour le système d'exploitation, dans lequel toutes les instructions machines sont autorisées, et le mode utilisateur, pour les programmes utilisateurs, pour lequel certaines instructions - par exemple d'E/S- sont interdites.
On peut considérer que le système MS-DOS et l'ensemble des fonctions qu'il propose, accessibles par l'interruption 21H appartient à cette classe de systèmes d'exploitation.
Au lieu d'appeler directement les procédures de traitement du service demandé, on peut créer un niveau intermédiaire : le "programme principal" du système d'exploitation appelle des procédures spécifiques de chaque service offert, qui appellent elles-mêmes des procédures utilitaires qui peuvent leur être communes comme le montre la figure ci-dessous :
Systèmes en couches
Cette organisation est une généralisation de l'exemple.
Chaque couche s'appuie sur la couche précédente.
Une méthodologie analogue a été utilisée pour définir la normalisation des communications dans les réseaux : la norme OSI à 7 couches.
On retrouve aussi l'idée de "machines virtuelles" empilées les unes sur les autres, vue plus haut.
Ce concept, tout à fait d'actualité (paquetages en ADA entre autres) est très ancien : la figure ci-dessous présente un exemple d'un tel système en couches proposé par Dijkstra en 1968 :
-
la couche 0 concerne l'allocation du processeur, passant d'un processus à un autre en cas d'interruption ou d'expiration du temps alloué (voir plus loin le chapitre "Allocation du/des processeur(s)"),
-
au-dessus, la couche 1 considère que tous les processus sont séquentiels, sans se soucier du fait qu'ils tournent sur un monoprocesseur.
La couche 0 fournit donc à la couche 1 la multiprogrammation du CPU. La couche 1 gère l'attribution de la mémoire principale aux processus ainsi que les échanges avec la mémoire secondaire
("swapping"),
-
la couche 2 gère les communications entre chaque processus et la console de l'opérateur.
Au-dessus de cette couche, chaque processus a sa propre console (n'oublions pas que les terminaux écrans n'existent pas encore !!!),
-
la couche 3 gère les E/S et les flots de données vers et à partir des buffers.
Au-dessus de cette couche, chaque processus n'est plus concerné que par des organes d'E/S abstraits, d'utilisation plus facile,
-
la couche 4 est constituée par les programmes utilisateurs.
Ils ne sont plus concernés par la gestion du processeur ou de la mémoire, par les E/S ou par la console,
-
la couche 5 est le processus utilisateur
C'est un développement ultérieur de cette organisation en couches qui a donné naissance à la structure du système MULTICS, ancêtre d'Unix, présentée généralement en anneaux concentriques ou "pelures d'oignon". Le cœur de ce schéma constitue le noyau (kernel).
Les procédures les plus intérieures sont les plus privilégiées.
Une procédure d'un anneau extérieur qui veut appeler une procédure plus intérieure doit exécuter une instruction spéciale TRAP équivalente au SVC vu précédemment (voir fonction système Unix syscall).
Les paramètres de cet appel sont soigneusement analysés avant que l'autorisation d'exécuter la procédure appelée ne soit donnée.
L'avantage de cette structure est de permettre d'ajouter des couches de plus en plus élaborées ou permettant d'ajouter des niveaux de contrôle supplémentaires à l'accès aux couches intérieures.
Le système Unix a longtemps été représenté sous cette forme :
En fait, la séparation en couches ou en anneaux est parfois artificielle et indéterminée : telle application, initialement appartenant au domaine des utilisateurs, devient d'un usage suffisamment courant pour justifier son intégration au niveau inférieur, devenant un utilitaire (par exemple les logiciels de présentation, menus, etc...).
De la même façon, certaines fonctions du logiciel de base, très spécialisées, deviennent du firmware (microcode) ou sont même directement intégrées au hardware.
Machines virtuelles
Nous avons déjà présenté précédemment ce concept.
Modèle client-serveur
Ce modèle traduit l'évolution vers des systèmes d'exploitation plus modernes.
L'idée est en opposition complète avec la tendance précédente qui consistait à intégrer de plus en plus d'outils au système d'exploitation.
Au contraire, il s'agit de réaliser des noyaux de plus en plus dépouillés.
Pour requérir un service, le processus client envoie une requête au processus serveur qui accomplit sa mission et renvoie la réponse.
Dans ce modèle, illustré ci-dessous, la seule fonction du noyau est la mise en communication du client avec le serveur.
Le fractionnement du système d'exploitation en parties dont chacune présente une facette du système d'exploitation (gestion des fichiers, des processus, des terminaux, de la mémoire, etc.) permet à chacune de ces parties d'être de taille beaucoup plus réduite et par-là même beaucoup plus facile à maintenir.
Les serveurs fonctionnent en mode utilisateur, et non en mode superviseur, et n'ont donc pas accès directement au hardware.
Il s'ensuit qu'un problème dans un des serveurs n'entraîne pas l'effondrement complet du système.
Un autre avantage du modèle "Client-serveur" est d'être utilisable dans un système distribué.
Quand un client communique avec un serveur de service, en lui envoyant un message, il n'a pas besoin de savoir si le message est traité localement sur sa propre machine ou s'il est envoyé à travers un réseau à un serveur sur une machine distante.
Dans les deux cas l'effet est le même : une demande a été faite et une réponse a été renvoyée.
Cette figure, qui montre le rôle du noyau limité au seul transport des messages, n'est pas très réaliste : certaines fonctions du système, telles que le chargement des commandes dans les registres de l'organe physique d'E/S, sont très difficiles sinon impossibles à effectuer depuis l'espace utilisateur.
Il y a deux façons de résoudre ce problème :
-
certains processus serveurs sont exécutés en mode superviseur (kernel mode) par exemple les pilotes des organes d'E/S, avec accès complet à tout le matériel (hardware), mais communiquent avec les autres processus par le mécanisme normal des messages,
-
une quantité minimale de mécanisme est mise dans le noyau, mais laisse les décisions de politique aux serveurs dans l'espace utilisateur.
Par exemple le noyau pourrait reconnaître qu'un message envoyé à une certaine adresse signifie "prendre le contenu de ce message et le charger dans les registres de l'organe d'E/S d'un disque", pour initialiser une lecture sur disque.
Dans cet exemple, le noyau ne regarderait même pas le contenu des octets d'un message pour savoir s'ils sont valides ou dénués de sens, il se contenterait de les copier "aveuglément" dans les registres de l'organe d'E/S.
Dernière mise à jour : 05/07/2001