WO1999040513A1 - Gestion des interruptions sur une plate-forme informatique - Google Patents

Gestion des interruptions sur une plate-forme informatique Download PDF

Info

Publication number
WO1999040513A1
WO1999040513A1 PCT/FR1999/000199 FR9900199W WO9940513A1 WO 1999040513 A1 WO1999040513 A1 WO 1999040513A1 FR 9900199 W FR9900199 W FR 9900199W WO 9940513 A1 WO9940513 A1 WO 9940513A1
Authority
WO
WIPO (PCT)
Prior art keywords
platform
interrupt
unit
management
interruptions
Prior art date
Application number
PCT/FR1999/000199
Other languages
English (en)
Inventor
Philippe Garrigues
Zoltan Menyhart
Original Assignee
Bull S.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull S.A. filed Critical Bull S.A.
Priority to EP99901674A priority Critical patent/EP0976040A1/fr
Priority to US09/402,394 priority patent/US6539436B2/en
Publication of WO1999040513A1 publication Critical patent/WO1999040513A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked

Definitions

  • the invention relates to the management of interruptions on a computer platform.
  • the platform also called machine or node
  • the platform comprises at least one unit (also called module).
  • a NUMA (Non Uniform Memory Access in English) type platform is particularly well suited to the invention and will therefore serve as an example in the description.
  • This platform comprises a plurality of units. On this type of platform, the units are interconnected.
  • a unit includes at least one processor.
  • This platform includes an operating system common to all the units and includes a kernel that the skilled person most often calls "kernel”.
  • the core performs a number of basic functions.
  • the two main functions of the kernel are memory management and task management.
  • the operating system offers the possibility of creating extension modules external to the kernel such as extension kernels. There is then in the system a basic kernel and extension kernels associated with device drivers. A “modern version” UNIX (registered trademark) type operating system is perfectly suited in this case.
  • the subject of the invention is a method for managing interruptions on a computer platform, as well as a computer platform for implementing the method.
  • task management by the operating system kernel includes taking into account and processing interruptions.
  • the management of interruptions depends on the number and type of devices present on the platform. Traps are associated with device drivers. Interrupt management is included in the operating system kernel.
  • the kernel is a source program written in an advanced language and is therefore subject, before its actual use, to compilation.
  • a compiler program is software that translates the entire program and then runs it.
  • the big problem is the intimate link between interrupt management and the operating system kernel. Compiling the kernel freezes a configuration state of the platform. As a result, a compilation freezes a maximum number of interrupts that can be supported by the operating system.
  • configuration designates the composition of a unit, that is to say the memory capacity, the types of floppy drives, the capacity of the hard disk, the type of printer, etc.
  • configuration also includes the number of units present on the platform.
  • Compiling the kernel therefore has the serious drawback of limiting the total number of interruptions.
  • This limitation is an obstacle to the exploitation of certain “large” configurations which evolve very quickly. Indeed, the frozen state of the system and the number of interruptions prevents a system from evolving. Adding or removing units on the platform becomes problematic.
  • a recompilation is also costly in time in the sense that it involves completely revalidating the operating system / platform pair. Indeed, the operating system kernel, following the recompilation, may not function or not systematically correspond to a platform. A new version of an operating system on a platform must undergo series of tests on all platforms subject to a change in its operating system
  • a solution provided by the prior art, to remedy the problem of compilation and the drawbacks which it entails, consists in that the kernels are generally sold compiled with a maximum of peripheral resource drivers in order to be compatible with a majority of types of peripheral resources We foresee, in a way, all the possible configurations on a platform This forecasting aspect has the serious consequence of an unnecessary expenditure of memory space for “small” configurations For example, a management system interruptions can provide for a number of interruptions of the order of a hundred thousand, while a small configuration system requires only ten interruptions
  • a NUMA type platform is generally made up of several units connected to each other through a bus The different units therefore communicate with each other via a single, so-called system bus.
  • a unit includes at least one processor surrounded by hardware elements such as memories, device drivers, etc.
  • a first object of the invention is to have management of interruptions adaptable to platforms whose configuration is constantly evolving, and thus not to impose recompilation of the basic kernel of the operating system following a modification of the platform configuration.
  • a second goal is to create an interface compatible with existing platforms.
  • Existing platforms will thus be able to preserve their basic core and a fortiori their own system for managing interruptions.
  • a third object of the invention is to have management of interruptions providing the processors with a performance gain.
  • a fourth goal is to significantly reduce the cost of money and time involved in changing the configuration of a platform.
  • the subject of the invention is a method for managing interruptions on a computer platform composed of at least one unit including at least one processor and at least one interrupt controller, of an operating system.
  • a basic kernel making it possible to create extension modules external to said basic kernel, characterized in that it consists in creating at least one extension management module for interrupts external to the basic kernel so as to unload the basic kernel of interrupt management.
  • the result is a computer platform comprising at least one unit including at least one processor and at least one interrupt controller, said platform including an operating system making it possible to create extension modules and lines of interruption connecting resources to controllers of interruption, characterized in that it comprises a software module for extending the management of interruptions for the implementation of the method.
  • FIG. 1 is a partial schematic view illustrating the architecture of a known platform on which the method according to the invention can be applied.
  • FIG. 2 is a partial schematic view used to illustrate the process according to the invention, the view including extension modules for managing the interruptions used by the process.
  • Figure 3 is a schematic view of the parameters included in each extension module shown in Figure 2.
  • FIG. 1 represents an example of a platform PF on which the invention can be applied.
  • the platform PF has two units M1 and M2.
  • the number of units is not limited to two but can be any number.
  • a unit usually has both physical and logical resources. For reasons of simplification, the term resources will be used to designate these two types of resources.
  • a unit, for example M1 comprises at least one processor PRO1 and PRO2, at least one memory MEM1, and at least one interrupt controller CM.
  • the unit M1 comprises a single interrupt controller CI1.
  • the M1 unit includes resources associated with device drivers noted IO1 in the drawing, such as as expansion cards or auxiliary circuits.
  • the unit M2 comprises at least one processor PRO3, PRO4 and PRO5, at least one memory MEM2 and at least one interrupt controller.
  • the unit M2 comprises a single interrupt controller CI2.
  • the unit M2 includes resources associated with device drivers denoted IO2.
  • a bus B1 connects the various peripheral resources to the interrupt controller CM.
  • Another bus connects the interrupt controller CM to the processors PRO1 and PRO2 and to the memory MEM1.
  • a bus B2 connects the various peripheral resources of the unit M2 to the interrupt controller CI2.
  • Another bus connects the interrupt controller CI2 to the processors PRO3, PRO4 and PRO5 and to the memory MEM2.
  • Interruption lines LU and LI2 connect the respective interruption controller CM and CI2 to the various resources.
  • the units are linked together via a BS bus called the system bus. Data transfer between the different units is carried out via this BS bus.
  • the CM and CI2 controllers only process one interrupt at a time.
  • the controllers CM and CI2 order and deliver, in a manner known to those skilled in the art, the interrupts to a processor according to the level of the interrupt to be processed.
  • the level of an interrupt depends on the priority that is assigned to a resource during initialization. It therefore manages the priorities of the various interrupts (also called interrupt level) emanating from the device drivers.
  • An operating system SE is common to the whole platform. This operating system includes a basic NOY kernel responsible for handling interrupts on the PF platform. In addition, the SE operating system allows you to load expansion modules external to the kernel such as expansion kernels.
  • the operating system SE is, for example, a UNIX type operating system "modern version”.
  • the interrupts are of both hardware and software type, known to those skilled in the art. Software interrupts are triggered by programs when they need to execute, for example a memory management function.
  • the called function is considered by the processor as a subroutine which, once completed, returns control to the caller Hardware and software interruptions are put on the same level, only the type of call distinguishes them
  • a software interruption it is the program which fixes the interruption number while in a hardware interruption, it is the device itself which takes care of it
  • the basic core NOY illustrated is common to all the units of the platform PF, in this case M1 and M2
  • the unit M1 comprises two processors and is linked to the core of NOY base
  • the M2 unit includes three processors and is linked to the same NOY base core
  • the problem is the very intimate link between the management of interrupts and the operating system kernel This link implies a complete recompilation of the basic NOY kernel with each update of the platform
  • An update can be the adding a unit or deleting a unit on the platform
  • An update also includes a modification of the configuration of a unit, for example M1
  • the method of the invention consists in creating at least one extension module for managing the interrupts MEX1 and MEX2 external to the basic kernel so as to unload the basic kernel NOY from managing the interrupts.
  • the method consists for example in associating, with each extension module for managing interruptions MEX1 and MEX 2, at least one respective unit M1 and M2
  • a “small” configuration means, for example, a configuration with a small number of units
  • the “large” configurations can include a large number of units
  • the platform can be of the “large” configuration type.
  • the processors lose their performance. It is therefore desirable to associate with a expansion module as few units as possible
  • each unit is associated with an extension module and therefore provides local interrupt management for each unit
  • the units M1 and M2 are associated to the respective extension modules MEX1 and MEX2
  • the platform can be of the “small” configuration type where the performance of the processors is not a determining factor.
  • the process can preferably consist in the creation of a single extension module. of the management of interrupts external to the basic kernel of the operating system In this example, all the units are managed through this single module
  • the method of the invention therefore consists, on each update, of recompiling only the extension module.
  • the compilation simply concerns the extension module associated with a unit on which a modification of the configuration has been brought
  • the compilation only concerns the one and only plug-in
  • Each extension module preferably has an administrative structure and allows either the use of a software or hardware management model
  • Both the software model and the hardware model involve two hierarchical software mechanisms, a primary mechanism and a secondary mechanism.
  • the main mechanism is responsible for memorizing an interrupt request and determines the priority associated with this interrupt, which the skilled person most often names the interrupt level
  • the main mechanism establishes an array containing the types of interruption and the associated priority
  • the main mechanism manages the interrupt controller, for example CM
  • the secondary mechanism is triggered directly following the second level mechanism
  • FIG. 3 is a schematic view parameters characterizing the new services offered by the platform and contained in the interruption management extension module
  • a processor for example PRO1
  • PRO1 is associated with an indexed pointer table, commonly called interruption vector, that the processor will consult in response to an interrupt
  • This table includes the address of the interrupt procedure associated with the interrupt request
  • the basic NOY kernel must export a function responsible for executing the registration of the new services offered by the extension module for managing interruptions, for example MEX1 In the example illustrated, it consists of inserting these new services into the table
  • This function can have six parameters, such as s as illustrated, which serve as an interface between the basic kernel and the interrupt management extension module. The number of parameters can be extended beyond six parameters to cover possible functionalities. All six parameters are associated with a device driver which itself is associated with an interrupt level
  • the first parameter P1 describes the address of a function which allows device drivers to register the addresses of their own interrupt management routines. To this end, two sub-parameters are used. A first sub-parameter allows identification of the interruption that the mechanism 10
  • a second sub-parameter allows the identification of the device driver itself so that it can be called.
  • This function makes use of the internal administration structure of the extension module for managing interruptions, for example MEX1.
  • This administration structure can be in the form of a table or a chain or a combination of the two and makes it possible to store the interruptions not yet processed.
  • the interrupt controller for example CM, emits an interrupt in the direction of the processor PRO1.
  • the processor PRO1 is interrupted at a determined interrupt level. At this level of interruption, it has a function queue which is stored in memory at determined addresses which it must call. These addresses correspond to interrupt routines associated with device drivers.
  • the processor calls all of these functions in cascade.
  • the second parameter P2 describes the address of a function which makes it possible to cancel the previous recording. If you decide to use a new device driver, this function eliminates the address of the corresponding interrupt routine from the previous table. The contents of the address table can therefore vary. The table is not frozen in time.
  • the third parameter P3 is similar to the first parameter P1 and describes the address of a function that allows device drivers to register the addresses of the exception routines in the event of a power failure. Indeed, such a failure prevents the complete completion of a task such as writing or reading on a disk of the platform.
  • the parameter P2 therefore corresponds in memory to the address of a routine to warn the device that the last transfer made is not valid. Under no circumstances should the device take this transfer into account and prevent the disk system from being inconsistent.
  • the fourth parameter P4 describes the address of a function which makes it possible to simulate by software the arrival of an external interrupt.
  • This simulation function presents the interrupt management extension module with a 11
  • This function performs processing identical to that which would have been carried out if the interrupt level had been that of a hardware interrupt sent by a coupler.
  • the electronic hardware card that links a peripheral resource to a processor is called a coupler.
  • This function can be used to test software. Thanks to this function, we avoid waiting for a real interruption to appear before testing the software specific to the invention. Preferably, this function is used to test the program already compiled in order to detect logic errors.
  • the fifth parameter P5 describes the address of the main interrupt management mechanism.
  • the main mechanism is called by the nucleus when the interruption occurs.
  • the parameter used identifies the processor.
  • the parameter also identifies the associated unit in the event that the platform has more than one unit.
  • the function associated with this parameter only calls the device drivers whose addresses appear in the internal administration structure.
  • the function records the fact that there has been an interruption in the internal administration structure.
  • this function signals to the basic kernel, via the exported function, that an interrupt is awaiting processing. The indication of the priority of the interrupt is provided in this function at this time. In both cases, this function is also responsible for acknowledging the interrupt at the interrupt logic level.
  • a sixth parameter P6 describes the address of the secondary interrupt management mechanism. This function is not called in the case of a hardware management model, the secondary mechanism being triggered directly following the processing of the interrupt by the main mechanism. This function is called in the case of a software management model. It calls this function if the priority indicated is more favorable than that being processed. 12
  • the subject of the invention is a method for managing interruptions on a computer platform PF composed of at least one unit M1 and M2 each including at least one respective processor PRO1-PRO2 and PRO3-PRO5 and at least one respective interrupt controller CM and CI2, of an operating system SE including a basic core NOY and making it possible to create extension modules external to said basic core, characterized in that it consists in creating at least one extension module for handling the interrupts MEX1 and MEX2 external to the basic kernel NOY so as to offload the basic kernel from interrupt management.
  • the update may consist in modifying the configuration of an M1 and / or M2 unit or else in adding or modifying the number of units on the PF platform.
  • a certain number of parameters define the new services offered by the platform PF after an update.
  • the method then consists, on initialization, for the basic NOY kernel, of exporting a function in the MEX1 and MEX2 extension module to record in its tables the addresses of the management functions it will have to use.
  • the method can consist in associating at least one respective unit M1 and M2 with each extension module for managing interruptions MEX1 and MEX2.
  • the method can consist of the creation of a single extension module for managing the interruptions common to the whole PF platform.
  • the method of the invention also preferably consists, for the extension module, of using either a software or hardware interrupt management model. 13
  • the result is a computer platform PF comprising at least one unit M1 and M2 including at least one respective processor PRO1-PRO2 and PRO3-PRO5 and at least one respective interrupt controller CM and CI2, said platform PF including a system of SE to create extension modules and interrupt lines L1 connecting resources to interrupt controllers CM and CI2, characterized in that it includes at least one software module for extending interrupt management for the implementation of the process.
  • the interrupt lines L1 connect a controller CM and CI2 of a respective unit M1 and M2 to all the resources of this same unit.
  • This interface is provided by at least one extension module for interrupt management.
  • This new interface does not require compilation of the basic operating system kernel in response to a change in the architecture of the platform.
  • Another advantage of the invention is the creation of an interface compatible with existing systems. Existing platforms will be able to preserve their basic core and a fortiori their system for managing interruptions. Also, more particularly on “large” configurations, the invention provides processors with a performance gain compared to current interrupt management systems because the management of interruptions is carried out on each unit.
  • the system may comprise only a single module for extending the interrupts. This variant may well be suitable for "small” platforms whose aim is not to improve the performance of the processors.
  • a last advantage of the invention is the considerable reduction in the cost of money caused by adding or removing a unit on a platform. Indeed, a modification of the configuration no longer requires to recompile the basic kernel of the operating system but simply a compilation of the extension module for handling interruptions.

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
Description
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. Il 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 plate-forme. 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. Il 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, l'é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/plate-forme. 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 plates- formes 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, l'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.
Il 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 PRO1 et PRO2, au moins une mémoire MEM1 , et au moins un contrôleur d'interruption CM . Dans l'exemple illustré, l'unité M1 comporte un seul contrôleur d'interruption CI1. L'unité M1 comporte des ressources associées à des pilotes de périphériques notés IO1 sur le dessin, tels que des cartes d'extension ou des circuits auxiliaires. De même, l'unité M2 comporte au moins un processeur PRO3, PRO4 et PRO5, 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 CI2. Dans l'exemple illustré, l'unité M2 comporte des ressources associées à des pilotes de périphériques notés IO2.
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 B1 relie les différentes ressources périphériques au contrôleur d'interruption CM . Un autre bus relie le contrôleur d'interruption CM aux processeurs PRO1 et PRO2 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 CI2. Un autre bus relie le contrôleur d'interruption CI2 aux processeurs PRO3, PRO4 et PRO5 et à la mémoire MEM2. Des lignes d'interruption LU et LI2 relient le contrôleur d'interruption respectif CM et CI2 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 CM et CI2 ne traitent qu'une interruption à la fois. Les contrôleur CM et CI2 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. Il 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 sous- programme 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 lui- mê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 M1 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 M1
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 « 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 a 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 charge 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' esta-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 CM 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 10
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 CM , émet une interruption en direction du processeur PRO1. Le processeur PRO1 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 P1 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 11
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. Il appelle cette fonction si la priorité indiquée est plus favorable que celle en cours de traitement. 12
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-PRO2 et PRO3-PRO5 et au moins un contrôleur d'interruption respectif CM et 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, 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é M1 et/ou 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. 13
Il en résulte une plate-forme informatique PF comprenant au moins une unité M1 et M2 incluant au moins un processeur respectif PRO1-PRO2 et PRO3- PRO5 et au moins un contrôleur d'interruption respectif CM et CI2, ladite plateforme PF incluant un système d'exploitation SE permettant de créer des modules d'extension et des lignes d'interruption Ll reliant les ressources aux contrôleurs d'interruption CM et CI2, 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 Ll relient un contrôleur CM et CI2 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, l'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 ,1e 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

14
R E V E N D I C A T I O N S
1 - 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 -PRO2, PRO3-PRO5) et au moins un contrôleur d'interruption respectif (CM , 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, 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 1 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 (PF).
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 1 à 5, caractérisé en ce qu'il consiste à associer au moins une unité respective (M1 , M2) à chaque module d'extension de gestion des interruptions (MEX1 , MEX2) 15
7 - Procédé selon l'une des revendications 1 à 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é (M1 , M2) incluant au moins un processeur respectif (PRO1-PRO2, PRO3-PRO5) et au moins un contrôleur d'interruption respectif (CM , CI2), ladite plate-forme (PF) incluant un système d'exploitation (SE) permettant de créer des modules d'extension et des lignes d'interruption (Ll) reliant les ressources aux contrôleurs d'interruption (CM , CI2), 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 (Ll) relient un contrôleur (CM , CI2) d'une unité respective (M1 , M2) à toutes les ressources de cette même unité.
PCT/FR1999/000199 1998-02-05 1999-02-01 Gestion des interruptions sur une plate-forme informatique WO1999040513A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP99901674A EP0976040A1 (fr) 1998-02-05 1999-02-01 Gestion des interruptions sur une plate-forme informatique
US09/402,394 US6539436B2 (en) 1998-02-05 1999-02-01 Management of interruptions in a computer platform

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9801363A FR2774489B1 (fr) 1998-02-05 1998-02-05 Gestion des interruptions sur une plate-forme informatique
FR98/01363 1998-02-05

Publications (1)

Publication Number Publication Date
WO1999040513A1 true WO1999040513A1 (fr) 1999-08-12

Family

ID=9522640

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR1999/000199 WO1999040513A1 (fr) 1998-02-05 1999-02-01 Gestion des interruptions sur une plate-forme informatique

Country Status (4)

Country Link
US (1) US6539436B2 (fr)
EP (1) EP0976040A1 (fr)
FR (1) FR2774489B1 (fr)
WO (1) WO1999040513A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7773630B2 (en) * 2005-11-12 2010-08-10 Liquid Computing Corportation High performance memory based communications interface
WO2007149745A2 (fr) * 2006-06-19 2007-12-27 Liquid Computing Corporation Procédés, systèmes et protocoles s'appliquant à des communications d'applications
US7873964B2 (en) 2006-10-30 2011-01-18 Liquid Computing Corporation Kernel functions for inter-processor communications in high performance multi-processor systems

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1992003783A1 (fr) * 1990-08-23 1992-03-05 Supercomputer Systems Limited Partnership Procede de mise en ×uvre des fonctions du noyau
US5553293A (en) * 1994-12-09 1996-09-03 International Business Machines Corporation Interprocessor interrupt processing system

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5515538A (en) * 1992-05-29 1996-05-07 Sun Microsystems, Inc. Apparatus and method for interrupt handling in a multi-threaded operating system kernel
US5752031A (en) * 1995-04-24 1998-05-12 Microsoft Corporation Queue object for controlling concurrency in a computer system
US5815707A (en) * 1995-10-19 1998-09-29 Hewlett-Packard Company Dynamic function replacement for streams framework
US6047323A (en) * 1995-10-19 2000-04-04 Hewlett-Packard Company Creation and migration of distributed streams in clusters of networked computers
US6349355B1 (en) * 1997-02-06 2002-02-19 Microsoft Corporation Sharing executable modules between user and kernel threads
US5913058A (en) * 1997-09-30 1999-06-15 Compaq Computer Corp. System and method for using a real mode bios interface to read physical disk sectors after the operating system has loaded and before the operating system device drivers have loaded

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1992003783A1 (fr) * 1990-08-23 1992-03-05 Supercomputer Systems Limited Partnership Procede de mise en ×uvre des fonctions du noyau
US5553293A (en) * 1994-12-09 1996-09-03 International Business Machines Corporation Interprocessor interrupt processing system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Weakening the Linux Kernel", PHRACK MAGAZINE, vol. 8, no. 52, 26 January 1998 (1998-01-26), http://www.phrack.com, pages 1 - 15, XP002084854 *
M. WELSH: "Implementing Loadable Kernel Modules for Linux", DR DOBB'S JOURNAL, vol. 20, no. 5, May 1995 (1995-05-01), Redwood City, US, pages 18-20,22,24,96, XP002084853 *

Also Published As

Publication number Publication date
FR2774489B1 (fr) 2000-03-03
US6539436B2 (en) 2003-03-25
EP0976040A1 (fr) 2000-02-02
FR2774489A1 (fr) 1999-08-06
US20020032821A1 (en) 2002-03-14

Similar Documents

Publication Publication Date Title
US10430318B1 (en) Systems and methods for efficiently performing regression testing on software updates
US20030233534A1 (en) Enhanced computer start-up methods
WO1995016246A1 (fr) Carte a memoire et procede de fonctionnement
US8683191B2 (en) Reconfiguring a secure system
FR2798204A1 (fr) Points d'interruption classes et methode de debogage des programmes informatiques
EP1290554B1 (fr) Systeme informatique modulaire et procede associe
FR2860894A1 (fr) Procede pour utiliser des indicateurs de fonction afin de determiner la compatibilite entre des revisions du bios et du materiel installe pendant une mise a jour de la memoire flash
US6374338B1 (en) Method for performing configuration tasks prior to and including memory configuration within a processor-based system
FR2685106A1 (fr) Systeme de commande d'interruption d'entree/sortie pour une machine virtuelle.
US8949588B1 (en) Mobile telephone as bootstrap device
WO1999040513A1 (fr) Gestion des interruptions sur une plate-forme informatique
EP2856323A1 (fr) Procede, dispositif et programme d'ordinateur de controle dynamique de distances d'acces memoire dans un systeme de type numa
CN110851183A (zh) 在多处理器体系结构中快速启动处理器的方法
US7103766B2 (en) System and method for making BIOS routine calls from different hardware partitions
US7100031B1 (en) Detector and operational method for a firmware interface
FR2639734A1 (fr) Ordinateur et procede de demarrage d'ordinateur
WO2011058260A1 (fr) Procede et dispositif d'optimisation d'execution d'applications logicielles dans une architecture multiprocesseur comprenant plusieurs controleurs d'entree/sortie et unites de calcul secondaires
EP2545449A1 (fr) Procédé de configuration d'un système informatique, programme d'ordinateur et système informatique correspondants
US10603583B1 (en) Entity-component architecture with components having multiple configurations
Krainyk et al. Information Technology for Configuration of System-on-Chip in Cloud Environment.
US20030097556A1 (en) Method and apparatus for providing simplified booting of domains in a multi-domain computer system
EP2717163B1 (fr) Procédé et dispositif de sauvegarde d'un état d'un circuit sous test émulé dans un émulateur et de son environnement de test logiciel, et procédé et dispositif de restauration correspondants
US11204781B2 (en) Optimizing power, memory and load time of a computing system during image loading based on image segmentation
FR2559928A1 (fr) Co-processeur microprogramme
CN115374051A (zh) SoC片上SRAM复用方法、电子设备及SoC芯片

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

REEP Request for entry into the european phase

Ref document number: 1999901674

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 1999901674

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 09402394

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 1999901674

Country of ref document: EP