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 s'exprimer plus précisément, le PnP consiste à allouer les "ressources" suivantes à la fois aux pilotes et au matériel : adresses d'E/S, IRQ, canaux DMA, régions mémoire. Si vous ne comprenez pas ce que signifient ces quatre notions, lisez les paragraphes suivants. Après que ces ressources ont été assignées, 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 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. 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 du PnP, "ressources" ne concerne qu'un sous-ensemble limité des ressources et "configuration" ne signifie qu'un certain type, seulement, de configuration.
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 et le 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" (logiciel qui fait partie du système d'exploitation et qui 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 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 une telle communication. Connaître une telle adresse correspond à mettre en oeuvre un canal de communication, même si ce "canal" est en réalité un bus de données dans le PC qui est partagé avec pratiquement tout le reste.
Les PC utilisent trois espaces d'adresses : mémoire principale, E/S, et configuration (uniquement dans le cas du bus PCI). Seuls les deux premiers (mémoire et E/S) sont configurés par le PnP. Les trois types d'adresses partagent le même bus à l'intérieur du PC. (De plus, dans le cas du bus PCI, le bus est également utilisé pour les données.) Mais la tension sur certains fils spécialisés indique à tous les périphériques si une adresse est, ou non, dans l'espace E/S ou dans l'espace mémoire centrale. Les périphériques sont normalement situés dans l'espace d'adressage E/S (bien que, dans certains cas ils soient également situés dans l'espace d'adressage mémoire centrale). Une adresse E/S (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 connaître 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 connaître 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 et si vous indiquez une adresse erronée au pilote, vous avez des problèmes. Maintenant, décrivons (dans les trois paragraphes suivants) quelques autres "ressources" qui peuvent être affectées : IRQ, Canaux DMA, et Régions mémoire. Tous ces éléments (y compris les adresses d'E/S) sont appelés "ressources".
Après avoir lu ce paragraphe, il faut lire Interruptions --Details 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. Dans ce cas, le périphérique a besoin de connaître l'adresse (ou quelque chose d'équivalent) de son pilote de périphérique afin de pouvoir l'appeler. Par exemple, le périphérique peut venir de recevoir un ensemble d'octets destinés à la mémoire centrale, et ce périphérique a besoin d'appeler son pilote pour qu'il vienne récupérer ces octets immédiatement et les transférer de la mémoire tampon, pratiquement pleine, du périphérique vers la mémoire centrale.
Le périphérique 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. Le périphérique doit connecter 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.
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.
Ne sont plus beaucoup utilisés puisque le véritable DMA ne concerne que le bus ISA et que l'équivalent du DMA pour le bus PCI est à la fois beaucoup plus rapide et ne nécessite pas de "canal DMA". 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 ne#####"ne"??##### peut se faire à 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 aussi bien que dans celui des E/S. Lorsque vous branchez une telle carte, en réalité vous connectez un module mémoire (de la mémoire principale, et pas seulement de la mémoire E/S). Cette mémoire est partagée entre le périphérique et le 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.
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, dans le cas d'un port série il y a seulement 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). 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).
L'architecture du PC fournit seulement un nombre limité d'IRQ, de canaux DMA, d'adresses d'E/S etc. 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 inévitables, 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.
L'allocation des ressources, si elle est correctement réalisée, établit également 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 rend bi-directionnel le canal de communication, où à la fois le pilote et le périphérique peuvent prendre l'initiative d'une communication.
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.
Cependant, un système d'exploitation PnP les détectera et saura quel modèle de périphérique est connecté. 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é "série" du PnP.