Ce que PnP doit faire : allouer des « ressources bus »

Si vous ne comprenez pas cette section, lisez Périphériques matériels et la communication avec ces derniers.

En simplifiant à l'extrême, Plug-and-Play indique aux pilotes de périphériques où trouver les différents matériels (périphériques) tels que modems, cartes réseau, cartes son, et cætera. La tâche du Plug-and-Play est de faire correspondre les périphériques physiques avec les logiciels (pilotes de périphériques) qui les font fonctionner, et d'établir des canaux de communication entre chaque périphérique physique et son pilote. Pour ce faire, PnP alloue les « ressources bus » suivantes aux matériels : adresses d'entrée/sortie, plages mémoire, IRQ, canaux DMA (uniquement pour les bus LPC et ISA). Ces quatre dernières sont parfois appelées des ressources de premier ordre ou simplement des ressources. PnP maintient un enregistrement de ce qu'il fait et autorise l'accès à ces informations aux pilotes de périphériques. Si vous ne comprenez pas ce que sont ces quatre ressources bus, lisez les sous-sections suivantes de ce guide pratique : Adresses d'entrée/sortie, IRQ, Canaux DMA, Régions mémoire. Un article de la Linux Gazette parle de trois des ressources bus. Il est disponible sur Introduction aux IRQ, DMA et adresses de base (NdT : une traduction française est disponible sur traduc.org). Une fois que ces ressources bus ont été assignées (et si le bon pilote est installé), le pilote actuel et ses « fichiers » du répertoire /dev sont prêt à être utilisés.

Cette méthode d'affectation PnP des ressources bus est parfois appelée « configuration » mais il s'agit seulement d'une configuration bas-niveau. Le répertoire /etc comprend beaucoup de fichiers de configuration mais un grand nombre d'entre eux ne concernent pas la configuration de PnP. Donc, la grande majorité des configurations de périphériques physiques n'a rien à voir avec PnP ou les ressources bus. Par exemple, l'initialisation d'un modem par une phrase d'initialisation ou la configuration de sa vitesse ne concerne pas PnP. Donc lorsque nous parlons de PnP, la configuration ne concerne qu'un seul type de configuration. Alors que d'autres documentations (telles que celles pour MS Windows) appellent les ressources bus « ressources », j'ai utilisé le terme de ressources bus au lieu du simple « ressources » pour les distinguer des nombreux autres types de ressources.

PnP est un long processus réalisé par différents logiciels et matériels. Si seul un programme gérait PnP sur Linux, cela serait simple. Mais, avec Linux, chaque pilote de périphérique fait son propre PnP en utilisant le logiciel fourni par le noyau. Le matériel du BIOS du PC utilise PnP au démarrage du PC. Et il y a bien plus que cela.

Un ordinateur est composé d'un processeur (CPU) réalisant les opérations et de mémoire vive (RAM) pour stocker les programmes et les données (en accès rapide). De plus, il existe de nombreux périphériques tels que différents types de disques, une carte vidéo, un clavier, des périphériques réseaux, des cartes modem, des périphériques sons, le bus USB, les ports séries et parallèles, et cætera. Dans les anciens temps, la plupart des périphériques étaient des cartes insérées dans des emplacements du PC. Aujourd'hui, beaucoup de périphériques, qui étaient auparavant des cartes, sont maintenant compris dans les composants intégrés à la carte-mère. On trouve aussi une alimentation apportant l'électricité, différents bus sur la carte mère pour connecter les périphériques au CPU et une boîte pour contenir le tout.

Les cartes se connectant sur la carte mère peuvent contenir plus d'un périphérique. Les cartes mémoires sont quelque fois considérées comme des périphériques mais ils ne sont pas Plug-and-Play si on suit le sens utilisé dans ce guide pratique.

Pour que l'ordinateur fonctionne bien, chaque périphérique doit être sous le contrôle de son « pilote ». Il s'agit d'un logiciel faisant partie du système d'exploitation, pouvant être chargé en tant que module et exécuté à partir du CPU. Les pilotes de périphériques sont associés à des « fichiers spéciaux » rangés dans le répertoire /dev, bien qu'ils ne soient pas vraiment des fichiers. Ils ont des noms tels que hda3 (troisième partition du disque a), ttyS1 (deuxième port série), eth0 (première carte Ethernet), et cætera.

Le périphérique eth0 est celui de la carte ethernet (carte réseau). Auparavant, il s'agissait de /dev/eth0 mais c'est maintenant un périphérique virtuel du noyau. Ce que eth0 référence dépend du type de carte ethernet que vous avez. Si le pilote est un module, cette affectation se trouve probablement dans une table interne du noyau mais pourrait aussi se trouver dans /etc/modules.conf (appelé « alias »). Par exemple, si vous disposez d'une carte ethernet utilisant le composant « tulip », vous devez placer la ligne « alias eth0 tulip » dans /etc/modules.conf pour que, lorsque votre PC cherche eth0, il trouve le pilote tulip. Néanmoins, les noyaux modernes peuvent généralement trouver le bon module du périphérique. De cette façon, vous n'aurez pas à le spécifier vous-même.

Pour contrôler un périphérique, le CPU (sous le contrôle du pilote de périphérique) envoie des commandes et des données du périphérique. Il reçoit aussi l'état et des données des différents périphériques. Pour cela, chaque pilote doit connaître l'adresse du périphérique qu'il doit contrôler. Connaître cette adresse revient à mettre en place un canal de communication, même si le « canal » physique se trouve être le bus de données interne au PC, bus partagé avec beaucoup d'autres périphériques.

Ce canal de communication est en fait un peu plus complexe que ce qui est décrit ci-dessus. Une « adresse » est en fait une plage d'adresses, ce qui fait que, parfois, le mot « plage » est utilisé à la place du mot « adresse ». Il peut exister plus d'une plage (sans recoupement) pour un seul périphérique. Il existe aussi un autre canal connu sous le nom d'interruptions permettant au périphérique d'envoyer une requête de « demande d'aide » urgente à leur pilote.

Le bus PCI a trois plages d'adressage : les entrées/sorties, la mémoire principale (mémoire d'entrées/sorties) et la configuration. L'ancien bus ISA ne dispose pas de cette dernière. Seules les entrées/sorties et la mémoire principale sont utilisées pour les entrées/sorties du périphérique. Les adresses de configuration sont fixes et ne peuvent pas être modifiées donc elles n'ont pas besoin d'être affectées. Pour plus d'informations, voir Espace d'adressage de la configuration PCI.

Quand le CPU veut accéder à un périphérique, il place l'adresse du périphérique sur un bus important de l'ordinateur (pour le PCI : le bus d'adresse/données). Tous les types d'adresses (tels que les entrées/sorties et la mémoire principale) partagent le même bus sur le PC. Mais la présence ou l'absence de voltage sur certains fils dédiés sur le bus du PC indique l'espace occupée par une adresse : entrée/sortie, mémoire principale (voir Espaces d'adressage) ou la configuration (seulement PCI). Ceci est un peu trop simplifié car indiquer à un périphérique PCI qu'il s'agit d'une adresse de configuration est réellement plus complexe que la description ci-dessus. Voir Espace d'adressage pour la configuration PCI pour plus d'informations. Voir Détails des adresses pour plus d'informations sur l'adressage en général.

Les adresses d'un périphérique sont stockées dans les registres du matériel physique. Elles peuvent être changées par logiciel et elles peuvent être désactivées pour que le périphérique ne soit plus adressable, sauf en ce qui concerne les adresses de configuration du PCI qui ne peuvent être ni modifiées ni désactivées.

Les périphériques étaient originellement situés dans la plage d'adresses des entrées/sorties mais, aujourd'hui, ils peuvent utiliser la plage en mémoire principale. Une adresse d'entrée/sortie est quelque fois simplement appelée « I/O », « IO », « i/o » ou « io ». Les termes « port I/O » ou « plage d'entrées/sorties » sont aussi utilisés. Ne confondez pas ces ports d'entrées/sorties avec la mémoire d'entrées/sorties située en mémoire principale. Il existe deux étapes principales pour allouer des adresses I/O (ou d'autres ressources bus telles que les interruptions sur le bus ISA) :

Souvent, le pilote du périphérique fait les deux (en quelque sorte). Le pilote de périphérique n'a pas réellement besoin d'initialiser une adresse d'entrée/sortie s'il découvre que l'adresse a déjà été initialisée (peut-être par le BIOS) et qu'il souhaite accepter cette adresse. Une fois que le pilote a soit trouvé une adresse précédemment configurée soit configuré l'adresse lui-même, alors il sait évidemment de quelle adresse il s'agit, donc il n'est pas nécessaire de lui fournir cette information -- il la connaît déjà.

Le processus en deux étapes ci-dessus (1. configurer l'adresse au niveau matériel. 2. mettre au courant le pilote.) ressemble aux deux parties d'un problème pour trouver le numéro de la maison d'une personne dans la rue. Quelqu'un doit installer un numéro sur l'entrée de la maison pour qu'elle puisse être trouvée, puis les personnes qui souhaitent aller à cette adresse doivent obtenir (et conserver) ce numéro pour qu'elles puissent trouver la maison. En informatique, le matériel du périphérique doit d'abord obtenir son adresse, qu'il placera dans un registre matériel spécial (ce qui revient à conserver le numéro dans notre exemple), puis le pilote de périphérique doit obtenir cette adresse (écrire ce numéro dans son carnet d'adresses). Les deux doivent être réalisés, soit automatiquement par le logiciel soit en saisissant manuellement des données dans des fichiers de configuration. Des problèmes pourraient survenir si seulement un des deux est fait correctement.

Pour la configuration manuelle de PnP, des personnes font l'erreur de ne faire qu'une de ces deux étapes et se demandent ensuite pourquoi l'ordinateur ne peut pas trouver le périphérique. Par exemple, ils utilisent setserial pour associer une adresse au port série sans réaliser que ceci ne fait que donner une adresse au pilote. Cela n'enregistre pas cette adresse au niveau du port série physique. Si vous avez dit une bêtise au port série, alors vous avez un problème. Une autre façon de parler au pilote est de donner l'adresse comme option au module du noyau (pilote de périphérique). Si ce que vous dites est faux, il peut y avoir des problèmes. Un pilote intelligent pourrait détecter comment le matériel est réellement configuré et rejeter les mauvaises informations fournies par l'option (ou au moins afficher un message d'erreur).

Un pré-requis évident est que le périphérique physique (comme une carte) doit connaître son adresse avant le pilote du périphérique. Comme les pilotes de périphérique se lancent souvent tout de suite après le démarrage de l'ordinateur, ils peuvent tenter d'accéder à une carte (pour vérifier sa présence, et cætera) avant que l'adresse ne soit enregistrée au niveau de la carte par le programme de configuration PnP. Et vous verrez un message d'erreur indiquant l'absence de la carte même si elle est bien dans le PC (mais n'a pas encore obtenue son adresse).

Ce qui a été dit dans les derniers paragraphes concernant les adresses I/O s'applique de la même manière à la majorité des autres ressources bus : la section intitulée « Plages mémoire », la section intitulée « IRQ - un aperçu » et la section intitulée « DMA (accès direct à la mémoire) ou maîtrise du bus ». Les trois prochaines sections expliqueront ce qu'ils sont. La seule exception est que les interruptions du bus PCI ne sont pas données par les registres d'une carte mais elles sont plutôt déroutées vers les IRQ par un composant de la carte mère. Ensuite, l'IRQ utilisée par cette carte PCI est inscrite dans un registre de la carte dans un but unique d'informer.

Pour voir quelles adresses d'entrées/sorties sont utilisées sur votre PC, regardez dans le fichier /proc/ioports.

Beaucoup de périphériques disposent d'une plage mémoire en mémoire principale. C'est quelquefois appelé « mémoire partagée » ou « mémoire d'entrées/sorties ». Cette mémoire est située physiquement dans le périphérique physique mais l'ordinateur y accède comme s'il accédait à des composants mémoire. En parlant de ressources bus, c'est souvent simplement appelé « mémoire », « mem », voire « iomem ». En plus de l'utilisation de cette « mémoire », un tel périphérique peut aussi utiliser une plage mémoire conventionnelle d'entrées/sorties. Pour connaître la mémoire utilisée sur votre ordinateur, cherchez dans /proc/iomem. Ce « fichier » inclut la mémoire utilisée par les composants mémoire habituels de la RAM, donc il affiche l'allocation mémoire en général et pas seulement l'allocation iomem. Si vous apercevez un numéro étrange au lieu d'un nom, c'est probablement le numéro d'un périphérique PCI, ce que vous pouvez vérifier en exécutant « lspci ».

Lorsque vous insérez une carte utilisant iomem, vous êtes aussi en train d'insérer un module mémoire pour la mémoire principale. Une adresse haute est sélectionnée pour lui par PnP de façon à ce que cela ne rentre pas en conflit avec les modules de la mémoire principale (composants). Cette mémoire peut être de la mémoire morte (ROM ou Read Only Memory) ou de la mémoire partagée. Cette dernière est partagée entre le périphérique et le CPU (ayant lancé le pilote du périphérique) de la même façon que la plage d'adresses d'entrées/sorties est partagée entre le périphérique et le CPU. Cette mémoire partagée sert en tant que moyen de « transfert » de données entre le périphérique et la mémoire principale. C'est de l'entrée/sortie mais ce n'est pas fait dans la plage d'adresses des entrées/sorties. La carte et le pilote doivent connaître la plage d'adresses.

La ROM (Read-Only Memory, soit mémoire en lecture seule) est un genre différent d'iomem. C'est plutôt un programme (parfois un pilote de périphérique), utilisé avec ce périphérique. Cela peut aussi être un code d'initialisation malgré que le pilote soit encore nécessaire. Avec un peu de chance, il fonctionnera aussi sous Linux, et pas seulement sous MS Windows. Elle peut être copiée en mémoire principale pour fonctionner plus rapidement. Mais dans ce cas, elle n'est plus « en lecture seule ».

Après avoir lu ceci, vous pouvez lire la section intitulée « Détails sur les interruptions » pour bien plus de détails. Ce qui suit est volontairement simplifié : en plus des adresses, il existe aussi un numéro d'interruption à gérer (tel que l'IRQ 5). Cela s'appelle un numéro d'IRQ (Interrupt ReQuest, ou demande d'interruption), ou plus simplement une « irq ». Nous avons déjà mentionné ci-dessus que le pilote de périphérique doit connaître l'adresse d'une carte pour être capable de communiquer avec elle.

Mais qu'en est-il de la communication en sens inverse ? Supposez que le périphérique ait besoin de dire quelque chose à son pilote immédiatement. Par exemple, le périphérique peut recevoir un grand nombre d'octets destinés à la mémoire principale et le tampon utilisé pour stocker ces octets est pratiquement plein. Du coup, le périphérique a besoin de demander à son pilote de récupérer ces octets avant que le tampon ne se voit dépassé par le flot continu d'octets. Un autre exemple serait de signaler au pilote que le périphérique a terminé d'envoyer un ensemble d'octets et qu'il attend maintenant de nouveaux octets à envoyer.

Comment le périphérique peut-il envoyer rapidement un signal à son pilote ? Il peut ne pas être capable d'utiliser le bus de données principal car il y a des chances qu'il soit déjà utilisé. Au lieu de cela, il place un voltage sur un fil d'interruption dédié (aussi appelé ligne ou trace) qui est souvent réservé pour ce seul périphérique. Ce signal est appelé une demande d'interruption (IRQ) ou plus simplement une « interruption ». Il existe l'équivalent de 16 (ou 24, et cætera.) fils de ce type dans un PC et chaque fil amène (indirectement) à un certain pilote de périphérique. Chaque fil a un numéro d'IRQ unique. Le périphérique doit placer son interruption sur le bon fil. Le fil sur lequel le périphérique envoie ces demandes d'aide est déterminé par le numéro d'IRQ enregistré dans le périphérique. Ce même numéro d'IRQ doit être connu par le pilote du périphérique pour que celui-ci sache quelle interruption écouter.

Une fois que le pilote reçoit l'interruption du périphérique, il doit trouver pourquoi cette interruption a été générée et agir de manière appropriée pour régler le problème. Sur le bus ISA, chaque périphérique a habituellement besoin de son propre numéro unique d'IRQ. Pour le bus PCI et dans d'autres cas spéciaux, le partage d'IRQ est autorisé (deux périphériques PCI, ou plus, pourraient avoir le même numéro d'IRQ). De même, pour le PCI, chaque périphérique PCI a un fil fixe PCI Interrupt. Mais un composant de routage programmable fait correspondre les fils PCI aux interruptions de type ISA. Voir la section intitulée « Détails sur les interruptions » pour savoir comment cela fonctionne.

Pour le bus PCI, DMA et maîtrise de bus signifient la même chose. Avant l'arrivée du bus PCI, la maîtrise du bus était rare et le DMA fonctionnait différemment et était lent. L'accès direct à la mémoire (DMA, acronyme de Direct Memory Access) est ce qui permet à un périphérique de prendre la main sur le bus principal de l'ordinateur et de transférer directement des octets vers la mémoire principale ou vers d'autres périphériques. Normalement, le processeur s'occupe des transferts d'un périphérique vers la mémoire principale par un processus en deux étapes :

Avec le DMA, il s'agit d'un processus en une seule étape consistant en l'envoi des octets directement du périphérique à la mémoire. Les périphériques doivent disposer de capacités DMA intégrées et, du coup, tous les périphériques ne peuvent pas faire de DMA. Alors que le DMA est en cours, le processeur ne peut pas faire grand chose car le bus principal est en cours d'utilisation par le transfert DMA.

L'ancien bus ISA peut faire du DMA lentement alors que le bus PCI peut faire du DMA par maîtrise du bus. Le bus LPC a à la fois l'ancien et le nouveau DMA (maîtrise du bus). Sur le bus PCI, ce qui devrait être appelé plus précisément « maîtrise du bus » est souvent appelé « Ultra DMA », « BM-DNA », « udma » ou tout simplement « DMA ». Sur le bus PCI, la maîtrise du bus est souvent appelé DMA. La maîtrise du bus permet aux périphériques de devenir temporairement les maîtres du bus et de transférer des octets un peu comme lorsque le maître du bus était le processeur. Il n'utilise aucun numéro de canal car l'organisation du bus PCI est telle que le matériel PCI sait quel périphérique est actuellement le maître du bus et quel périphérique réclame à devenir le maître du bus. Du coup, il n'y a pas d'allocation de ressources pour les canaux DMA pour le bus PCI et aucune ressource de canaux DMA n'existe pour ce bus. Le bus LPC est supposé être configuré par le BIOS pour que les utilisateurs n'aient pas à se soucier des canaux DMA.

C'est seulement pour l'ancien bus ISA et le bus LPC. Quand un périphérique veut faire du DMA, il lance une requête de DMA en utilisant les fils dédiés à cela, un peu comme une requête d'interruption. En fait, le DMA aurait pû être géré en utilisant des interruptions mais cela aurait introduit des délais, donc il est plus rapide de faire cela en ayant un type spécial d'interruption connu en tant que requête DMA. Comme les interruptions, les demandes DMA sont numérotées pour identifier le périphérique lançant la requête. Ce nombre est appelé un canal DMA. Comme les transferts DMA utilisant tous le bus principal (et qu'un seul peut être lancé à la fois), ils utilisent tous les même canal pour le flot de données mais le numéro de « canal DMA » sert à identifier qui utilise le canal. Les registres matériels existent sur la carte mère, qui enregistre l'état actuel de chaque canal. Du coup, pour lancer une requête DMA, le périphérique doit connaître son numéro de canal DMA stocké dans un registre spécial du périphérique physique.

Donc, les pilotes de périphériques doivent être « attachés » d'une façon quelconque au matériel qu'ils contrôlent. Ceci se fait en allouant des ressources bus (I/O, mémoire, IRQ, DMA) au périphérique physique et en laissant le pilote le découvrir. Par exemple, un port série utilise seulement deux ressources : une IRQ et une adresse d'entrées/sorties. Ces deux valeurs doivent être fournies au pilote et au périphérique physique. Le pilote (et son périphérique) dispose d'un nom dans le répertoire /dev (tel que ttyS1). L'adresse et le numéro IRQ sont stockés par le périphérique physique dans ses registres de configuration sur sa carte (ou dans un composant de la carte mère). Les vieux matériels (dans les années 1990) utilisaient des interrupteurs (ou des cavaliers) pour configurer physiquement l'IRQ et l'adresse au niveau du matériel. Ce paramétrage restera fixe tant qu'une personne n'enlevera pas le boîtier pour déplacer les cavaliers.

Mais, dans le cas de PnP (pas de cavaliers), les données du registre de configuration sont habituellement perdues lorsque le PC est éteint, donc les données des ressources bus doivent être fournies à chaque périphérique à chaque allumage du PC.

L'architecture du PC n'apporte qu'un nombre limité de ressources : IRQ, canaux DMA, adresses d'entrées/sorties et de plages mémoires. S'il n'existait qu'un nombre limité de périphériques et qu'ils aient tous des ressources bus standardisées (telles que des adresses d'entrées/sorties et des numéros d'IRQ uniques), il n'y aurait aucun souci pour attacher un pilote à son périphérique. Chaque périphérique devrait avoir un nombre fixe de ressources qui n'entreraient pas en conflit avec tout autre périphérique sur votre ordinateur. Deux périphériques ne devraient pas avoir les mêmes adresses, il n'y aurait pas de conflit d'IRQ sur le bus ISA, et cætera. Chaque pilote devrait être développé avec des adresses, des IRQ, et cætera, uniques codées en dur dans le programme. La vie serait simple.

Une autre façon d'empêcher les conflits d'adresses serait d'avoir un numéro d'emplacement, inclus dans l'adresse, pour chaque carte. Du coup, il n'y aurait plus de conflits d'adresses entre deux cartes différentes (car elles sont dans des emplacements différents). La conception des cartes ne permettrait pas les conflits d'adresses entre les différentes fonctions de la carte. Il en ressort que l'espace d'adressage (utilisé pour la demande et l'affectation de ressources) le fait réellement. Mais cela n'est pas pris en compte pour les adresses d'entrées/sorties et pour les régions mémoire. Partager des IRQ comme sur le bus PCI évite aussi des conflits mais peut poser d'autres problèmes.

Mais l'architecture du PC a des problèmes de conflit. L'augmentation du nombre de périphériques (incluant les multiples périphériques de même type) a tendance à augmenter les conflits potentiels. En même temps, l'introduction du bus PCI, où deux périphériques ou plus peuvent partager la même interruption et l'introduction d'interruptions supplémentaires, a tendance à réduire les conflits. Le résultat global, dû au passage au PCI, a été une réduction des conflits car les ressources les plus faibles sont les IRQ. Néanmoins, même sur le bus PCI, c'est un peu plus efficace pour éviter le partage des IRQ. Dans certains cas où les interruptions arrivent en une succession rapide et doivent être traitées rapidement (comme en audio), le partage peut causer des dégradations dans les performances. Donc, il n'est pas bon d'affecter tous les périphériques PCI au même IRQ, l'affectation doit être partagée. Néanmoins, certaines personnes trouvent que tous les périphériques PCI sont sur la même IRQ.

Donc, les périphériques ont besoin d'avoir de la flexibilité de façon à ce qu'ils puissent être initialisés avec n'importe quelle adresse, IRQ, et cætera. C'est nécessaire pour éviter tout conflit et arriver à un point d'équilibre. Mais quelques IRQ et adresses sont pratiquement des standards, comme ceux de l'horloge et du clavier. Ils n'ont pas besoin d'une telle flexibilité.

En plus du problème de conflit lors de l'allocation des ressources bus, une indication erronée en indiquant au pilote de périphérique quelles sont les ressources bus peut causer un autre problème. Cela a plus de chances d'arriver dans le cas de la configuration manuelle où l'utilisateur saisit les ressources utilisées dans un fichier de configuration sur le disque dur. Ceci fonctionne généralement bien quand les ressources sont initialisées avec des cavaliers sur les cartes (en supposant que l'utilisateur sache comment elles étaient initialisées et n'a fait aucune faute en saisissant ces données dans les fichiers de configuration). Mais, avec des ressources configurées par un logiciel PnP, elles ne seront pas toujours identiques et cela pourrait poser problème pour toute configuration manuelle où l'utilisateur saisit les valeurs des ressources bus configurées par PnP.

L'allocation de ressources bus, lorsqu'elle est faite correctement, établit des canaux de communications sans conflit entre le matériel physique et le pilote associé. Par exemple, si une certaine plage mémoire d'entrées/sorties (ressource) est allouée à la fois au pilote de périphérique et au matériel, alors cela a établi une communication sur une voie à sens unique entre eux. Le pilote peut envoyer des commandes et des informations au périphérique. C'est donc un peu plus qu'une voie à sens unique car le pilote peut obtenir des informations du périphérique en lisant ces registres. Mais le périphérique ne peut pas initier une communication de cette façon. Pour initier une communication, le périphérique a besoin d'une IRQ pour qu'il puisse envoyer une interruption à son pilote. Ceci crée un canal de communication à double-sens où le périphérique physique et son pilote peuvent initier une communication.