FR2774489A1

FR2774489A1 - Gestion des interruptions sur une plate-forme informatique

Info

Publication number: FR2774489A1
Application number: FR9801363A
Authority: FR
Inventors: Philippe Garrigues; Zoltan Menyhart
Original assignee: Bull SA
Current assignee: Bull SA
Priority date: 1998-02-05
Filing date: 1998-02-05
Publication date: 1999-08-06
Anticipated expiration: 2018-02-05
Also published as: US6539436B2; WO1999040513A1; EP0976040A1; US20020032821A1; FR2774489B1

Abstract

Sur une plate-forme informatique (PF) composée d'au moins une unité (M1, M2) incluant chacune au moins un processeur respectif (PRO1-PRO2, PRO3-PRO5) et au moins un contrôleur d'interruption respectif (CI1, CI2), d'un système d'exploitation (SE) incluant un noyau de base (NOY) et permettant de créer des modules d'extension externes audit noyau de base, on crée au moins un module d'extension de la gestion des interruptions (MEX1, MEX2) externe au noyau de base (NOY) de façon à décharger le noyau de base de la gestion des interruptions.

Description

Titre : Gestion des interruptions sur une plate-forme informatique Descrintion
Domaine technique
L'invention concerne la gestion des interruptions sur une plate-forme informatique. La plate-forme (aussi appelée machine ou noeud) sur laquelle s'applique l'invention comprend au moins une unité ( aussi appelée module). Une plate-forme de type NUMA (Non Uniform Memory Access en anglais) est particulièrement bien adaptée à l'invention et servira donc d'exemple dans la desccription. Cette plate-forme comporte une pluralité d'unités. Sur ce type de plate-forme, les unités sont reliées entre elles. Une unité comporte au moins un processeur. Cette plate-forme comporte un système d'exploitation commun à toutes les unités et inclut un noyau que l'homme du métier nomme le plus souvent kernel . Le noyau assure un certain nombre de fonctions de base. Les deux fonctions principales du noyau sont la gestion de la mémoire et celle des tâches.

Dans l'invention, le système d'exploitation offre la possibilité de créer des modules d'extension externe au noyau tel que des noyaux d'extension. II existe alors dans le système un noyau de base et des noyaux d'extension associés à des pilotes de périphériques. Un système d'exploitation de type UNIX (marque déposée) version moderne est tout à fait adapté dans le cas présent.

L'invention a pour objet un procédé de gestion des interruptions sur une plate-forme informatique, ainsi qu'une plate-forme informatique pour la mise en oeuvre du procédé.

L'art antérieur
Par définition, sur une plate-forme informatique, la gestion des tâches par le noyau du système d'exploitation comprend la prise en compte et le traitement des interruptions. La gestion des interruptions dépend du nombre et du type de périphériques présents sur la plate4orme Les interruptions sont associées à des pilotes de périphériques. La gestion des interruptions est incluse dans le noyau du système d'exploitation. Par définition, le noyau est un programme source écrit dans un langage évolué et est donc sujet, avant son utilisation effective, à une compilation. Un programme compilateur désigne un logiciel qui traduit le programme en entier et puis l'exécute.

Le gros problème est le lien intime existant entre la gestion des interruptions et le noyau du système d'exploitation. La compilation du noyau fige un état de configuration de la plate-forme. II en résulte qu'une compilation fige un nombre maximum d'interruptions supportable par le système d'exploitation. Dans la description, le terme configuration désigne la composition d'une unité, c'est-à-dire la capacité de la mémoire, les types de lecteurs de disquettes, la capacité du disque dur, le type d'imprimante, etc. Le terme de configuration inclut aussi le nombre d'unités présentes sur la plate-forme.

La compilation du noyau a donc le grave inconvénient de limiter le nombre total des interruptions. Cette limitation est un frein à l'exploitation de certaines grosses configurations qui évoluent très rapidement. En effet, I'état figé du système et du nombre d'interruptions empêche un système d'évoluer. L'ajout ou la suppression d'unités sur la plate-forme devient problématique.

Un autre problème est qu'une simple modification de la configuration matérielle implique une modification de la gestion des interruptions et donc du programme source dans le noyau. Cette modification du programme implique une recompilation complète du noyau de base. Or, il est connu de l'homme du métier qu'une recompilation du noyau du système d'exploitation est fortement coûteuse en argent.

Une recompilation est coûteuse aussi en temps en ce sens qu'elle implique de revalider complètement le couple système d'exploitationîplate4orme. En effet, le noyau du système d'exploitation, suite à la recompilation, peut ne pas fonctionner ou ne pas correspondre systématiquement à une plate-forme. Une nouvelle version d'un système d'exploitation sur une plate-forme doit subir des séries de tests sur toutes les plates-formes sujettes à un changement de son système d'exploitation.

Une solution apportée par l'art antérieur, pour remédier au problème de la compilation et des inconvénients qu'elle entraîne, consiste en ce que les noyaux sont généralement vendus compilés avec un maximum de pilotes de ressources périphériques dans le but d'être compatibles avec une majorité de types de ressources périphériques. On prévoit, en quelque sorte, toutes les configurations possibles sur une plate-forme. Cet aspect prévisionnel a pour conséquence grave une dépense inutile d'espace mémoire pour des petites configurations. Par exemple, un système de gestion des interruptions peut prévoir un nombre d'interruptions de l'ordre de cent mille, alors qu'un système de petite configuration n'exige qu'une dizaine d'interruptions.

Un autre gros problème est la perte de performance du travail des processeurs sur une plate-forme suite à l'évolution constante des plates-formes.

Une plate-forme de type NUMA est généralement constituée de plusieurs unités reliées entre elles par l'intermédiaire d'un bus. Les différentes unités communiquent donc entre elles par l'intermédiaire d'un seul et unique bus dit bus système. Une unité inclut au moins un processeur entouré d'éléments matériels tels que des mémoires, des pilotes de périphériques, etc. Or la tendance actuelle est la multiplication des unités sur une plate-forme. Le trafic des données d'une unité à l'autre devient de plus en plus important et le bus permettant la communication entre les unités est assimilé à un tuyau d'étranglement. A ce transfert de données, il faut ajouter la gestion des interruptions. Dans ce type de système à plusieurs unités, la gestion des interruptions s'effectue au niveau global du système. La multiplication des unités sur une plate-forme rend difficile la gestion des interruptions. En effet, dans ce type de système multi-unités, il est connu de l'homme du métier que le temps d'accès par un processeur à la mémoire varie selon la localisation des données accédées. Pour un processeur considéré, on distingue les accès à une partie de mémoire locale, située physiquement sur la même unité que le processeur, et les accès à une partie de mémoire distante, située physiquement sur un ou plusieurs autres unités que celui où est situé le processeur. Un processeur sera d'autant plus performant que ses éléments matériels constituant l'unité sur lequel il travaille seront proches de lui en terme de distance.

L'invention
Un premier but de l'invention est de disposer d'une gestion des interruptions adaptable aux plates-formes dont la configuration évolue constamment, et ainsi de ne pas imposer de recompilation du noyau de base du système d'exploitation suite à une modification de la configuration de la plate-forme.

Un deuxième but est de créer une interface compatible avec les platesformes existantes. Les plates-formes existantes pourront ainsi préserver leur noyau de base et a fortiori leur propre système de gestion des interruptions.

Un troisième but de l'invention est de disposer d'une gestion des interruptions procurant aux processeurs un gain de performance.

Un quatrième but est de réduire considérablement le coût en argent et en temps qu'occasionne la modification de la configuration d'une plate-forme.

A cet effet, I'invention a pour objet un procédé de gestion des interruptions sur une plate-forme informatique composée d'au moins une unité incluant au moins un processeur et au moins un contrôleur d'interruption, d'un système d'exploitation incluant un noyau de base permettant de créer des modules d'extension externes audit noyau de base, caractérisé en ce qu'il consiste à créer au moins un module d'extension de la gestion des interruptions externe au noyau de base de façon à décharger le noyau de base de la gestion des interruptions.

II en résulte une plate-forme informatique comportant au moins une unité incluant au moins un processeur et au moins un contrôleur d'interruption, ladite plate-forme incluant un système d'exploitation permettant de créer des modules d'extension et des lignes d'interruption reliant les ressources aux contrôleurs d'interruption, caractérisé en ce qu'elle comprend un module logiciel d'extension de la gestion des interruptions pour la mise en oeuvre du procédé.

L'invention sera mieux comprise à la lecture de la description qui suit donnée à titre d'exemple et faite en référence aux dessins annexés.

Dans les dessins:
- la figure 1 est une vue schématique partielle illustrant l'architecture d'une plate-forme connue sur laquelle peut s'appliquer le procédé conforme à l'invention.

- la figure 2 est une vue schématique partielle servant à illustrer le procédé conforme à l'invention, la vue incluant des modules d'extension de la gestion des interruptions utilisés par le procédé.

- la figure 3 est une vue schématique des paramètres inclus dans chaque module d'extension représenté sur la figure 2.

Pour simplifier la description, dans les dessins les mêmes éléments portent les mêmes références.

La figure 1 représente un exemple d'une plate-forme PF sur laquelle peut s'appliquer l'invention. Dans l'exemple illustré, la plate-forme PF a deux unités M1 et M2. Le nombre d'unités n'est pas limité à deux mais peut être un nombre quelconque. Une unité comporte généralement des ressources à la fois physiques et logiques. Pour des raisons de simplification, on utilisera le terme ressources pour désigner ces deux types de ressources. Une unité, par exemple
M1, comporte au moins un processeur PROi et PR02, au moins une mémoire
MEMI, et au moins un contrôleur d'interruption Cli. Dans l'exemple illustré, L'unité M1 comporte un seul contrôleur d'interruption Cli. L'unité M1 comporte des ressources associées à des pilotes de périphériques notés 101 sur le dessin, tels que des cartes d'extension ou des circuits auxiliaires. De même, L'unité M2 comporte au moins un processeur PR03, PR04 et PR05, au moins une mémoire
MEM2 et au moins un contrôleur d'interruption. Dans l'exemple illustré, L'unité M2 comporte un seul contrôleur d'interruptions C12. Dans l'exemple illustré, L'unité M2 comporte des ressources associées à des pilotes de périphériques notés 102.

Dans une unité, par exemple l'unité M1, les différentes ressources sont reliées par l'intermédiaire de bus. Dans l'exemple illustré, un bus Bi relie les différentes ressources périphériques au contrôleur d'interruption Cli. Un autre bus relie le contrôleur d'interruption Cli aux processeurs PROl et PR02 et à la mémoire MEM1. De même, un bus B2 relie les différentes ressources périphériques de l'unité M2 au contrôleur d'interruption Cl2. Un autre bus relie le contrôleur d'interruption C12 aux processeurs PR03, PR04 et PR05 et à la mémoire MEM2. Des lignes d'interruption LII et L12 relient le contrôleur d'interruption respectif Cli et Cl2 aux différentes ressources. Les unités sont reliées entre elles par l'intermédiaire d'un bus BS appelé bus système. Le transfert de données entre les différentes unités s'effectue par l'intermédiaire de ce bus BS.

Les contrôleurs Cli et C12 ne traitent qu'une interruption à la fois. Les contrôleur Cli et C12 ordonnent et délivrent, de façon connue de l'homme du métier, les interruptions à un processeur en fonction du niveau de l'interruption à traiter. Le niveau d'une interruption est fonction de la priorité que l'on attribue à une ressource lors de l'initialisation. II gère donc les priorités des différentes interruptions (appelé aussi niveau d'interruption) émanant des pilotes de périphériques.

Un système d'exploitation SE est commun à toute la plate-forme. Ce système d'exploitation inclut un noyau de base NOY responsable de la gestion des interruptions sur la plate-forme PF. De plus, le système d'exploitation SE permet de charger des modules d'extension externes au noyau tels que des noyaux d'extension. Le système d'exploitation SE est, par exemple, un système d'exploitation de type UNIX version moderne . Sur la plate-forme, les interruptions sont de type à la fois matérielles et logicielles, connues de l'homme du métier. Les interruptions logicielles sont déclenchées par les programmes lorsqu'ils ont besoin d'exécuter, par exemple, une fonction de gestion de la mémoire. La fonction appelée est considérée par le processeur comme un sousprogramme qui, une fois achevée, rend le contrôle à l'appelant. Les interruptions matérielles et logicielles sont mises sur le même plan, seul le type d'appel les distingue. Dans une interruption logicielle, c'est le programme qui fixe le numéro d'interruption tandis que dans une interruption matérielle, c'est le périphérique luimême qui s'en charge.

Dans la figure 2, le noyau de base NOY illustré est commun à toutes les unités de la plate-forme PF, en l'occurrence Mi et M2. Dans l'exemple illustré,
L'unité M1 comprend deux processeurs et est liée au noyau de base NOY. De même, L'unité M2 comprend trois processeurs et est liée au même noyau de base
NOY.

Le problème est le lien très intime existant entre la gestion des interruptions et le noyau du système d'exploitation. Ce lien implique une recompilation complète du noyau de base NOY à chaque mise à jour de la plate-forme. Une mise à jour peut être l'ajout d'une unité ou la suppression d'une unité sur la plateforme. Une mise à jour inclut aussi une modification de la configuration d'une unité, par exemple Mi.

A cet effet, le procédé de l'invention consiste à créer au moins un module d'extension de la gestion des interruptions MEX1 et MEX2 externe au noyau de base de façon à décharger le noyau de base NOY de la gestion des interruptions.

Ces modules sont donc des programmes.

Le procédé consiste par exemple à associer, à chaque module d'extension de gestion des interruptions MEX1 et MEX 2, au moins une unité respective M1 et
M2.

Le choix du nombre de modules d'extension est surtout fonction du type de configuration de la plate-forme. On distingue, généralement, les petites et les grandes configurations. Une a petite configuration désigne, par exemple, une configuration avec un faible nombre d'unités. D'un autre côté, les grosses configurations peuvent comporter un grand nombre d'unités.

Selon une première variante, la plate-forme peut être du type grosse configuration. Dans ce type de configurations, pour les raisons évoquées dans l'introduction de la description, les processeurs perdent de leur performance. II est donc souhaitable d'associer à un module d'extension le moins possible d'unités. Dans l'exemple illustré, chaque unité est associée à un module d'extension et fournit donc une gestion des interruptions locale à chaque unité.

Dans l'exemple illustré, les unités M1 et M2 sont associées aux modules d'extension respectifs MEX1 et MEX2.

Selon une autre variante, la plate-formne peut être du type petite configuration où la performance des processeurs n'est pas un facteur déterminant. Le procédé peut, de préférence, consister en la création d'un seul et unique module d'extension de la gestion des interruptions externe au noyau de base du système d'exploitation. Dans cet exemple, toutes les unités sont gérées par l'intermédiaire de cet unique module.

Le procédé de l'invention consiste donc, à chaque mise à jour à recompiler uniquement le module d'extension. Sur une grosse configuration, la compilation concerne simplement le module d'extension associé à une unité sur laquelle une modification de la configuration a été apportée. Sur une petite configuration, la compilation concerne uniquement le seul et unique module d'extension.

Chaque module d'extension a de préférence une structure d'administration et autorise indifféremment l'utilisation d'un modèle de gestion logiciel ou matériel.

Le modèle logiciel aussi bien que le modèle matériel font intervenir deux mécanismes logiciels hiérarchisés : un mécanisme principal et un mécanisme secondaire.

Pour un modèle de gestion logiciel, le mécanisme principal est chargé de mémoriser une demande d'interruption et détermine la priorité associée à cette interruption, que l'homme du métier nomme le plus souvent niveau d'interruption.

A cet effet, et à titre d'exemple, le mécanisme principal établit un tableau contenant les types d'interruption et la priorité associée. Ce modèle s'articule autour d'une gestion différée des interruptions. En effet, le mécanisme principal déclenche le mécanisme secondaire une fois que le système est disponible, c'està-dire lorsque le système aura effectué toutes les tâches prioritaires par rapport au niveau de priorité de l'interruption en question. Les tâches peuvent être une écriture, une lecture, etc.

Pour un modèle de gestion matériel le mécanisme principal gère le contrôleur d'interruption, par exemple Cl1. Le mécanisme secondaire est déclenché directement à la suite du mécanisme de deuxième niveau.

Dans la phase d'initialisation (boot), c'est-à-dire au démarrage, il y a lieu de faire connaître au noyau de base les adresses des fonctions de gestion qu'il aura à utiliser. La figure 3 est une vue schématique des paramètres caractérisant les nouveaux services offerts par la plate-forme et contenus dans le module d'extension de gestion des interruptions. On associe à un processeur, par exemple PRO1, une table de pointeurs, indexée, appelée communément vecteur d'interruption, que le processeur consultera en réponse à une interruption. Cette table comprend l'adresse de la procédure d'interruption associée à la demande d'interruption. Avant toute chose, le noyau de base NOY doit exporter une fonction chargée d'exécuter l'enregistrement des nouveaux services proposés par le module d'extension de gestion des interruptions, par exemple MEX1. Dans l'exemple illustré, il consiste à insérer ces nouveaux services dans la table. Cette fonction peut comporter six paramètres, tels qu'illustrés, qui servent d'interface entre le noyau de base et le module d'extension de gestion des interruptions. Le nombre de paramètres est extensible au-delà de six paramètres pour couvrir d'éventuelles fonctionnalités. L'ensemble des six paramètres est associé à un pilote de périphérique qui lui-même est associé à un niveau d'interruption.

Le premier paramètre P1 décrit l'adresse d'une fonction qui permet aux pilotes de périphériques d'enregistrer les adresses de leurs propres routines de gestion des interruptions. A cette fin, deux sous-paramètres sont utilisés. Un premier sous-paramètre permet l'identification de l'interruption que le mécanisme va gérer. Un deuxième sous-paramètre permet l'identification du pilote de périphérique lui-même pour pouvoir être appelé. Cette fonction fait usage de la structure d'administration interne au module d'extension de gestion des interruptions, par exemple MEX1. Cette structure d'administration peut se présenter sous forme de tableau ou de chaîne ou d'une combinaison des deux et permet de mémoriser les interruptions non encore traitées. Concrètement, le contrôleur d'interruption, par exemple Cli, émet une interruption en direction du processeur PROU. Le processeur PROl est interrompu à un niveau d'interruption déterminé. A ce niveau d'interruption, il a une file de fonction qui se trouve en mémoire à des adresses déterminées qu'il doit appeler. A ces adresses correspond des routines d'interruption associées à des pilotes de périphériques.

Le processeur appellent toutes ces fonctions en cascade.

Le deuxième paramètre P2 décrit l'adresse d'une fonction qui permet d'annuler l'enregistrement précédent. Si on décide d'utiliser un nouveau pilote de périphérique, cette fonction élimine de la table précédente l'adresse de la routine d'interruption correspondante. Le contenu de la table des adresses peut donc varier. La table n'est pas figée dans le temps.

Le troisième paramètre P3 est semblable au premier paramètre Pi et décrit l'adresse d'une fonction qui permet aux pilotes de périphériques d'enregistrer les adresses des routines d'exception en cas de coupure de l'alimentation secteur.

En effet, une telle défaillance empêche la réalisation complète d'une tâche comme une écriture ou une lecture sur un disque de la plate-forme. Le paramètre
P2 correspond donc en mémoire à l'adresse d'une routine pour prévenir le périphérique que le dernier transfert effectué n'est pas valable. Le périphérique ne doit en aucun cas prendre en compte ce transfert et éviter que le système de disque ne soit incohérent.

Le quatrième paramètre P4 décrit l'adresse d'une fonction qui permet de simuler par logiciel l'arrivée d'une interruption externe. Cette fonction de simulation présente au module d'extension de gestion des interruptions une situation identique à celle que l'on trouve lorsqu'on reçoit une véritable interruption externe. Cette fonction effectue un traitement identique à celui qui aurait été effectué si le niveau d'interruption avait été celui d'une interruption matérielle envoyée par un coupleur. On appelle coupleur, la carte matérielle électronique qui fait le lien entre une ressource périphérique et un processeur.

Cette fonction peut permettre de tester un logiciel. Grâce à cette fonction, on évite d'attendre qu'une véritable interruption se manifeste pour tester le logiciel propre à l'invention. De préférence, cette fonction sert à tester le programme déjà compilé afin d'y détecter les erreurs de logique.

Le cinquième paramètre P5 décrit l'adresse du mécanisme principal de gestion des interruptions. Le mécanisme principal est appelé par le noyau lorsque l'interruption se manifeste. Le paramètre utilisé permet d'identifier le processeur.

Le paramètre permet aussi d'identifié l'unité associée dans l'hypothèse ou la plate-forme comporte plus d'une unité.

Dans le cas d'un modèle de gestion matériel, la fonction associée à ce paramètre se contente d'appeler les pilotes de périphérique dont les adresses figurent dans la structure d'administration interne.

Dans le cas d'un modèle de gestion logiciel, la fonction enregistre le fait qu'il y a eu une interruption dans la structure d'administration interne. De plus, cette fonction signale au noyau de base, par l'intermédiaire de la fonction exportée, qu'une interruption est en attente de traitement. L'indication de la priorité de l'interruption est fournie dans cette fonction à ce moment-là. Dans les deux cas, cette fonction est aussi en charge d'acquitter l'interruption au niveau de la logique d'interruption.

Un sixième paramètre P6 décrit l'adresse du mécanisme secondaire de gestion des interruptions. Cette fonction n'est pas appelée dans le cas d'un modèle de gestion matériel, le mécanisme secondaire se déclenchant directement suite au traitement de l'interruption par le mécanisme principal. Cette fonction est appelée dans le cas d'un modèle de gestion logiciel. II appelle cette fonction si la priorité indiquée est plus favorable que celle en cours de traitement.

D'une manière générale, on peut dire que l'invention a pour objet un procédé de gestion des interruptions sur une plate-forme informatique PF composée d'au moins une unité M1 et M2 incluant chacune au moins un processeur respectif PRO1-PR02 et PR03-PR05 et au moins un contrôleur d'interruption respectif Cli et Cl2, d'un système d'exploitation SE incluant un noyau de base NOY et permettant de créer des modules d'extension externes audit noyau de base, caractérisé en ce qu'il consiste à créer au moins un module d'extension de la gestion des interruptions MEX1 et MEX2 externe au noyau de base NOY de façon à décharger le noyau de base de la gestion des interruptions.

En particulier, grâce au procédé, si la configuration de la plate-forme PF est modifiée lors d'une mise à jour, il suffit de recompiler uniquement le module d'extension associé à l'unité qui a été modifiée. La mise à jour peut consister à modifier la configuration d'une unité Mi etlou M2 ou bien à ajouter ou modifier le nombre d'unités sur la plate-forme PF.

De préférence, un certain nombre de paramètres définissent les nouveaux services proposés par la plate-forme PF après une mise à jour. Le procédé consiste alors, à l'initialisation, pour le noyau de base NOY, à exporter une fonction dans le module d'extension MEX1 et MEX2 pour enregistrer dans ses tables les adresses des fonctions de gestion qu'il aura à utiliser.

Dans un exemple, on a vu que le procédé peut consister à associer au moins une unité respective M1 et M2 à chaque module d'extension de gestion des interruptions MEX1 et MEX2. Dans un autre exemple, on a vu que le procédé peut consister en la création d'un seul et unique module d'extension de la gestion des interruptions commun à toute la plate-forme PF.

Le procédé de l'invention consiste aussi, de préférence, pour le module d'extension, à utiliser indifféremment un modèle de gestion des interruptions logiciel ou matériel.

II en résulte une plate-forme informatique PF comprenant au moins une unité Ml et M2 incluant au moins un processeur respectif PROI-PR02 et PR03 PR05 et au moins un contrôleur d'interruption respectif Cli et Cl2, ladite plateforme PF incluant un système d'exploitation SE permettant de créer des modules d'extension et des lignes d'interruption LI reliant les ressources aux contrôleurs d'interruption Cli et C12, caractérisé en ce qu'elle comprend au moins un module logiciel d'extension de la gestion des interruptions pour la mise en oeuvre du procédé. Dans un exemple, les lignes d'interruption LI relient un contrôleur Cli et
C12 d'une unité respective M1 et M2 à toutes les ressources de cette même unité.

II ressort aussi des exemples illustrés que l'invention offre de nombreux avantages. Elle remédie au problème lié à l'évolution constante des plates-formes actuelles. On dispose avec l'invention d'une interface de gestion des interruptions adaptables aux nouvelles plates-formes. Cette interface est procurée par au moins un module d'extension de gestion des interruptions. Cette nouvelle interface n'impose pas de compilation du noyau de base du système d'exploitation en réponse à une modification de l'architecture de la plate-forme.

Un autre avantage de l'invention est la création d'une interface compatible avec les systèmes existants. Les plates-formes existantes pourront préserver leur noyau de base et a fortiori leur système de gestion des interruptions. Aussi, plus particulièrement sur les grandes configurations, I'invention procure aux processeurs un gain de performance par rapport aux systèmes de gestion des interruptions actuels du fait que la gestion des interruptions est déportée sur chaque unité. Selon une autre variante ,le système peut ne comporter qu'un unique module d'extension des interruptions. Cette variante peut tout à fait convenir à des petites plates-formes dont le but recherché n'est pas un gain en perfomance des processeurs. Et enfin, un dernier avantage de l'invention est la réduction considérable du coût en argent qu'occasionne l'ajout ou la suppression d'une unité sur une plate-forme. En effet, une modification de la configuration n'impose plus de recompiler le noyau de base du système d'exploitation mais simplement une compilation du module d'extension de la gestion des interruptions.

Claims

REVENDICATIONS

1 - Procédé de gestion des interruptions sur une plate-forme informatique (PF) composée d'au moins une unité (Ml) et (M2) incluant chacune au moins un processeur respectif (PROl-PRO2, PR03-PR05) et au moins un contrôleur d'interruption respectif (Cl1, C12), d'un système d'exploitation (SE) incluant un noyau de base (NOY) et permettant de créer des modules d'extension externes audit noyau de base, caractérisé en ce qu'il consiste à créer au moins un module d'extension de la gestion des interruptions (MEX1, MEX2) externe au noyau de base (NOY) de façon à décharger le noyau de base de la gestion des interruptions.

2 - Procédé selon la revendication 1, caractérisé en ce qu'il consiste, si la configuration de la plate-forme (PF) est modifiée lors d'une mise à jour, à recompiler uniquement le module d'extension associé à l'unité qui a été modifiée.

3 - Procédé selon la revendication i ou 2, caractérisé en ce qu'il consiste, pour une mise à jour, à modifier la configuration d'une unité (M1) et/ou (M2).

4 - Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il consiste, pour une mise à jour, à ajouter ou modifier le nombre d'unités sur la plate-forme (pif).

5 - Procédé selon l'une des revendications 1 à 4, caractérisé en ce qu'il consiste, à l'initialisation, pour le noyau de base (NOY), à exporter une fonction dans le module d'extension (MEX1, MEX2) pour enregistrer dans ses tables les adresses des fonctions de gestion qu'il aura à utiliser.

6 - Procédé selon l'une des revendications I à 5, caractérisé en ce qu'il consiste à associer au moins une unité respective (Ml, M2) à chaque module d'extension de gestion des interruptions (MEXI, MEX2).

7 - Procédé selon l'une des revendications i à 6, caractérisé en ce qu'il consiste à créer un seul et unique module d'extension de la gestion des interruptions commun à toute la plate-forme.

8 - Procédé selon l'une des revendications 1 à 7, caractérisé en qu'il consiste, pour le module d'extension, à utiliser indifféremment un modèle de gestion des interruptions logiciel ou matériel.

9 - Plate-forme informatique (PF) comportant au moins une unité (Ml, M2) incluant au moins un processeur respectif (PROl-PRO2, PR03-PR05) et au moins un contrôleur d'interruption respectif (Cl1, Cl2), ladite plate-forme (PF) incluant un système d'exploitation (SE) permettant de créer des modules d'extension et des lignes d'interruption (LI) reliant les ressources aux contrôleurs d'interruption (Cl1, C12), caractérisé en ce qu'elle comprend un module logiciel d'extension de la gestion des interruptions pour la mise en oeuvre le procédé des revendications 1 à 8.

10 - Plate-forme selon la revendication 9, caractérisé en ce que les lignes d'interruption (LI) relient un contrôleur (Cl1, Cl2) d'une unité respective (Ml, M2) à toutes les ressources de cette même unité.