En simplifiant beaucoup, le Plug-and-Play est une méthode pour indiquer automatiquement au logiciel (pilotes de périphériques) où trouver différents éléments matériels (périphériques) tels que modems, cartes réseau, cartes son etc. La tâche du Plug-and-Play consiste à mettre en correspondance les périphériques physiques et les logiciels (pilotes de périphériques) qui les font fonctionner et à établir un canal de communication entre chaque périphérique et son pilote. Pour ce faire, le PnP alloue les "ressources bus" suivantes à la fois aux pilotes et au matériel : adresses d'E/S, IRQ, canaux DMA (uniquement pour le bus ISA), régions mémoire. Si vous ne comprenez pas ce que signifient ces quatre notions, lisez les paragraphes suivants. Après que ces ressources du bus ont été assignées (et si les pilotes adéquats sont installés), les noms des unités périphériques dans le répertoire /dev sont prêts à être utilisés.
Cette méthode d'affectation de certaines ressources du bus est quelquefois désignée par le terme "configuration", mais c'est uniquement d'une configuration de bas niveau qu'il s'agit. Même lorsque le PnP est utilisé au maximum, une bonne partie de la configuration des périphériques est réalisée par autre chose que le PnP. Par exemple, pour la configuration du modem, une "chaîne de caractères d'initialisation" est envoyée au modem à travers le "canal" adresse d'E/S. Cette "chaîne de caractères d'initialisation" n'a rien à voir avec le PnP bien que le "canal" utilisé pour l'envoyer ait été alloué par le PnP. Le réglage de la vitesse (et de beaucoup d'autres paramètres) d'un port série est réalisé en envoyant, de programmes exécutés par l'utilisateur (souvent automatiquement, au démarrage), des messages au pilote de périphérique. Et cette configuration n'a rien à voir avec le PnP. Donc, quand on parle de la configuration effectuée par lePnP, cela ne concerne qu'un certain type de configuration. Alors que d'autres documentations (telle celle de MS Windows) parlent simplement de "ressources" quand il s'agit des ressources du bus, j'ai volontairement utilisé le terme "ressources du bus" pour les distinguer de la multitude d'autres ressources disponibles.
Un ordinateur est constitué d'un CPU/processeur qui effectue les traitements, et de mémoire pour stocker les programmes et les données. De plus, il y a un certain nombre de périphériques tels que différents types d'unité de disques, une carte vidéo, un clavier, des cartes réseau, des cartes modem, des cartes son, des ports série et parallèle etc. Il y a également une alimentation pour fournir l'énergie nécessaire, différents bus sur une carte mère pour connecter les périphériques au CPU, ainsi qu'un boîtier pour contenir le tout.
Dans les temps anciens, la plupart des périphériques avaient leur propre carte d'interface (circuits imprimés). Aujourd'hui, en plus des cartes d'interface, beaucoup de "périphériques" sont de petits circuits montés de façon permanente sur une carte unique appelée "carte mère". Les cartes qui se connectent sur la carte mère peuvent contenir plus d'un périphérique. Les circuits mémoire sont quelquefois également considérés comme des périphériques mais ne sont pas plug-and-play au sens de cet HOWTO.
Pour qu'un système informatique fonctionne correctement, chaque unité périphérique doit être sous le contrôle de son "pilote de périphérique" Ce logiciel fait partie du système d'exploitation (ou d'un module) et tourne sur le CPU. Les pilotes de périphériques sont associés à des "fichiers spéciaux" dans le répertoire /dev, bien que ce ne soient pas vraiment des fichiers. Ils ont des noms tels que hda1 (première partition sur le disque dur a), ttyS0 (premier port série), eth1 (deuxième carte Ethernet) etc. Pour rendre les choses plus compliquées, le pilote de périphérique sélectionné, disons pour eth1, dépendra du type de carte Ethernet que vous aurez. Donc, eth1 ne peut pas être affecté à n'importe quel pilote Ethernet, mais à un certain pilote qui fonctionnera avec le type de carte que vous avez installé. Pour gérer un périphérique, le CPU (sous le contrôle du pilote de périphérique), envoie des commandes (et des données) vers les différents périphériques et en lit les infos. Pour cela, chaque pilote de périphérique doit connaître l'adresse utilisée pour le périphérique qu'il gère. Connaître une telle adresse correspond à mettre en oeuvre un canal de communication, même si le "canal" physique est en réalité un bus de données dans le PC qui est partagé avec pratiquement tout le reste.
Le canal de communication est en réalité un peu plus compliqué que la description qui en est faite ci-dessus. Une "adresse" est en réalité un ensemble d'adresses et il y a un canal inverse (les interruptions) qui permet aux périphériques d'envoyer, en urgence, une requête de "demande d'aide" au pilote de périphérique.
Les PC utilisent trois espaces d'adresses : mémoire principale, E/S, et configuration (uniquement dans le cas du bus PCI). Les trois types d'adresses partagent le même bus à l'intérieur du PC. Mais la tension sur certains fils spécialisés indique à tous les périphériques à quel "espace" une adresse appartient : E/S, mémoire centrale, ou configuration. Consultez Adresses pour plus de détails. Les périphériques sont normalement situés dans l'espace d'adressage E/S bien que, maintenant ils utilisent l'espace d'adressage mémoire centrale. Une adresse E/S (Entrée/Sortie) (ou I/0, pour Input/Output) est quelquefois appelée simplement "I/O", "IO", "i/o" ou "io". Le terme "port d'E/S" (ou "I/O port") est également utilisé. Il y a deux étapes principales pour allouer les adresses d'E/S (ou d'autres ressources telles que les interruptions) :
Le processus en deux étapes ci-dessus ressemble un peu au problème de la recherche du numéro de la maison de quelqu'un dans une rue. Vous devez obtenir (et noter) le numéro de la maison et quelqu'un doit avoir apposé le numéro sur la maison afin qu'on puisse le trouver. Dans les ordinateurs, le pilote de périphérique doit obtenir l'adresse, et le matériel du périphérique doit installer la même adresse dans l'un de ses registres. Ces deux opérations doivent être réalisées, mais certains font l'erreur de ne réaliser que l'une de ces deux étapes et se demandent ensuite pourquoi l'ordinateur ne peut pas trouver le périphérique. Par exemple, ils utiliseront "setserial" pour attribuer une adresse à un port série, sans penser que cela indique seulement au pilote quelle est cette adresse. Cela ne sélectionne pas l'adresse physique du port série lui-même. Si le port série a, en réalité, une adresse différente (ou pas d'adresse du tout)et que vous indiquiez une adresse erronée a setserial, vous avez des problèmes.
Une autre obligation, évidente, consiste a avoir paramétré l'adresse d'E/S sur la carte avant que le pilote de périphérique n'essaie d'utiliser cette adresse. Comme les pilotes de périphériques démarrent souvent dès la mise en route de l'ordinateur, ils essaient quelquefois d'accéder à une carte (pour tester sa présence etc. ) avant que l'adresse ait été paramétrée dans la carte par le programme de configuration PnP. Ainsi, vous voyez des messages d'erreur indiquant qu'une carte est introuvable bien qu'elle soit présente (mais son adresse n'a pas encore été attribuée).
Ce qui vient d'être dit dans les deux derniers paragraphes concernant les adresses d'E/S s'applique avec la même force aux autres ressources : Les IRQ --Vue d'ensemble, Canaux DMA,et Espace mémoire. C'est ce que nous allons expliquer dans les trois paragraphes suivants.
Après avoir lu ce paragraphe, il faut lire Interruptions --Détails pour avoir quelques détails complémentaires. Ce qui suit est volontairement très simplifié : en plus de l'adresse, il faut également prendre en compte un numéro d'interruption (tel que IRQ5), que l'on appelle également numéro d'IRQ (IRQ = Interrupt ReQuest, demande d'interruption). Nous avons déjà mentionné plus haut que le pilote de périphérique doit connaître l'adresse de la carte de façon à pouvoir communiquer avec elle. Mais comment se fait la communication dans l'autre sens ? Supposons que le périphérique ait besoin de dire quelque chose à son pilote immédiatement. Par exemple, le périphérique peut venir de recevoir une rafale d'octets destinés à aller en mémoire centrale et que le périphérique ait besoin de demander à son pilote de venir les récupérer immédiatement de sa mémoire tampon pratiquement pleine pour les transférer en mémoire centrale.
Comment le périphérique peut-il appeler son pilote à l'aide ? Il ne peut pas utiliser le bus de données principal puisque celui-ci est déjà en cours d'utilisation. Au lieu de cela, il lance un appel en mettant une certaine tension sur une ligne d'interruption (qui fait partie du bus). Il y a l'équivalent de 16 lignes, et chacune d'elle correspond (indirectement) à un certain pilote de périphérique. Chaque ligne possède un numéro d'interruption (IRQ) unique (IRQ = Interrupt ReQuest). Le périphérique doit envoyer son interruption sur la bonne ligne et le pilote de périphérique doit attendre l'interruption sur cette ligne. Le numéro d'IRQ stocké dans le périphérique détermine quelle est la ligne concernée. Ce même numéro d'IRQ doit être connu du pilote de périphérique de manière que celui-ci sache quelle ligne d'IRQ le concerne.
Lorsqu'un pilote de périphérique reçoit une interruption (un appel à l'aide) il doit se renseigner sur la cause de l'émission de cette interruption et effectuer les actions appropriées pour y répondre. Sur un bus ISA chaque périphérique a besoin d'un numéro d'interruption unique (sauf que deux ports série ou plus peuvent partager la même interruption depuis le noyau 2.2). Sur un bus PCI, le partage des interruptions est permis.
Les canaux DMA ne concernent que le bus ISA. DMA signifie "Accès Direct Mémoire" (Direct Memory Access). Dans ce cas, le périphérique est autorisé à prendre le pas sur le CPU pour le contrôle du bus et à transférer les octets directement en mémoire centrale. Normalement le CPU effectuerait un tel transfert en deux étapes :
Le bus PCI n'a pas vraiment de DMA, mais plutôt quelque chose de mieux : le "contrôle du bus" (bus mastering). Cela fonctionne un peu comme le DMA et on l'appelle quelquefois DMA (par exemple, les unités de disques durs se nomment "UltraDMA"). Cette technique permet aux périphériques de prendre temporairement le contrôle du bus et de transférer des octets exactement comme le fait le CPU lorsqu'il a le contrôle du bus. On n'utilise pas de numéros de canaux car le bus PCI est constitué de telle manière que le matériel sait quel est le contrôleur du bus actuel et quel est le périphérique qui demande à le devenir. Il n'y a donc pas d'allocation de canaux DMA dans le cas d'un bus PCI.
Quand un périphérique, sur un bus ISA, désire effectuer un transfert DMA, il génère une requête de DMA en utilisant une ligne spécialisée comme pour une demande d'interruption. Le DMA aurait pu être réalisé en utilisant les interruptions mais cela aurait introduit des retards, donc il est plus rapide d'utiliser un type d'interruption spécial connu sous le nom de requête DMA. Comme les interruptions, les requêtes DMA sont numérotées de façon à identifier le périphérique qui a envoyé cette requête. Ce numéro est appelé canal DMA. Puisque tous les transferts DMA utilisent le bus principal (et qu'un seul utilisateur ne peut utiliser ce bus à un instant donné) ils utilisent tous le même canal, mais le numéro de "canal DMA" sert à identifier qui est en train d'utiliser le "canal". Des registres existent sur la carte mère pour stocker l'état courant de chaque "canal". Donc, pour émettre une requête DMA, le périphérique doit connaître son numéro de canal DMA qui doit être stocké dans un registre sur le périphérique physique.
Certains périphériques se voient assigner des adresses dans l'espace de la mémoire principale. On parle souvent de "mémoire partagée" ou "d'E/S en zone mémoire". Quelquefois, il s'agit de mémoire morte (ROM) sur le périphérique. A propos de ressources PnP, on parle simplement de "mémoire". Un tel périphérique peut également utiliser l'espace d'adressage E/S.
Lorsque vous branchez une telle carte, en réalité vous connectez un module mémoire pour la mémoire principale. Cette mémoire peut être soit de la mémoire morte (ROM = Read Only Memory) soit de la mémoire partagée. La mémoire partagée est partagée entre le périphérique et l'Unité Centrale (CPU qui exécute le pilote de périphérique). Cette mémoire peut servir de moyen de "transfert" direct des données entre le périphérique et la mémoire principale. En réalité, ce n'est pas un transfert à proprement parler puisque le périphérique met ses données dans sa propre mémoire qui se trouve être également la mémoire centrale. À la fois la carte et le pilote de périphérique doivent savoir où cela se passe. Il faut utiliser des adresses mémoires hautes de façon à éviter tout conflit avec les circuits mémoires des adresses basses (de la mémoire centrale) de votre ordinateur.
Pour la ROM, c'est différent. C'est comme un programme (peut-être le pilote de périphérique) qui serait utilisé avec le périphérique. Heureusement, il peut tourner avec Linux et pas seulement avec Windows ?? Il peut être nécessaire de le dupliquer en mémoire centrale pour le faire tourner plus vite. Une fois dupliqué, il n'est plus "en lecture seule".
Donc, les pilotes de périphériques doivent être "attachés" d'une façon quelconque au matériel qu'ils contrôlent. Cela est réalisé en fournissant des "ressources" (E/S, Mémoire, IRQ, DMA) à la fois au périphérique physique et au logiciel de pilotage. Par exemple, un port série n'utilise seulement que 2 ressources (parmi les 4 possibles) : une IRQ et une adresse d'E/S. Ces deux valeurs doivent être fournies au pilote de périphérique et au périphérique physique. On donne alors un nom (tel que ttyS1) au pilote (et à l'unité périphérique correspondante) dans le répertoire /dev. L'adresse et le numéro d'IRQ sont stockés dans un registre sur la carte du périphérique physique (ou dans un circuit sur la carte mère). Si l'on utilise de cavaliers, cette information est toujours stockée dans la partie "matériel" du périphérique (sur la carte etc.). Mais dans le cas du PnP, la donnée enregistrée est généralement perdue lors de l'arrêt du PC (mise hors tension) de sorte que cette donnée doit être fournie à chaque fois que le PC est remis en fonction.
L'architecture du PC fournit seulement un nombre limité d'IRQ, de canaux DMA, d'adresses d'E/S et de régions mémoire. S'il n'y avait que quelques périphériques et qu'ils aient des ressources standardisées (comme des adresses d'E/S et des numéros d'IRQ uniques) il n'y aurait aucun problème pour attacher des pilotes de périphériques aux unités périphériques. Chaque unité aurait des ressources fixes qui n'entreraient en conflit avec aucune autre unité périphérique de l'ordinateur. Deux périphériques n'auraient pas la même adresse d'E/S, la même IRQ etc. Chaque pilote pourrait être programmé avec l'adresse d'E/S, l'IRQ etc. codées en dur dans le programme. La vie serait simple.
Mais ce n'est pas le cas. Non seulement il existe tellement de périphériques différents aujourd'hui que les conflits sont fréquents, mais, de plus, on a souvent besoin d'avoir plus d'un périphérique d'un type donné. Par exemple, on peut vouloir disposer de plusieurs unités de disques différentes, de plusieurs ports série etc. Pour ces raisons, les périphériques doivent être paramètrables afin que l'on puisse leur attribuer les adresses, IRQ etc. que l'on désire pour éviter les conflits. Mais quelques IRQ et adresses sont tout à fait standard comme celles de l'horloge et du clavier. Elles ne nécessitent pas une telle adaptabilité.
En dehors du problème de conflit d'allocation des ressources, il y a le problème de l'erreur en communiquant la nature des ressources au pilote de périphérique. Par exemple, supposons que vous ayez entré IRQ 4 dans un fichier de configuration alors que le périphérique utilise, en réalité, l'IRQ 5. C'est un autre type d'erreur dans l'allocation des ressources du bus.
L'allocation des ressources du bus, si elle est correctement réalisée, établit des canaux de communication entre les périphériques physiques et leurs pilotes. Par exemple, si une certaine gamme d'adresses d'E/S (ressource) est allouée à la fois à un pilote de périphérique et à un matériel, alors on a établi un canal de communication à sens unique entre eux. Le pilote peut envoyer des commandes et des informations au périphérique. C'est, en réalité, un peu plus qu'un canal à sens unique puisque le pilote peut obtenir des informations du périphérique en consultant ses registres. Mais le périphérique ne peut pas prendre l'initiative d'une communication de cette façon. L'allocation d'une IRQ est nécessaire pour créer un canal de communication bi-directionnel, où à la fois le pilote et le périphérique peuvent prendre l'initiative d'une communication.
Les périphériques externes qui se connectent au port série par un câble (comme les modems externes) peuvent également être appelés Plug-and-Play Puisque seul le port série lui-même nécessite des ressources (une IRQ et une adresse d'E/S), il n'y a pas de ressources à allouer à un périphérique qui se connecte à un tel port. Donc, le PnP n'a pas vraiment de raison d'être pour ces périphériques. Cela, même s'il y a des spécifications PnP pour de tels périphériques série.
Un système d'exploitation PnP les détectera et saura lire leur numéro de modèle etc. Il sera donc alors capable de trouver un pilote de périphérique adapté et vous n'aurez pas à dire à un programme d'application que vous utilisez disons, /dev/ttyS1. Mais puisque vous devriez être capable d'indiquer manuellement à votre ordinateur (par l'intermédiaire d'un fichier de configuration etc.) sur quel port série votre périphérique est connecté (et éventuellement le modèle dont il s'agit) vous n'avez pas réellement besoin de cette fonctionnalité "port série" du PnP.