Guide pratique Plug-and-Play

Merci de m'indiquer toute erreur, que ce soit dans les faits, les opinions, la logique, l'orthographe, la grammaire, la clarté, les liens, etc. Mais tout d'abord, si la date du document est vieille de plus de quelques mois, vérifiez que vous possédez bien la dernière version. Envoyez-moi toute information que vous trouvez intéressante pour ce document.

Je n'ai pas encore étudié le code utilisé par les différents pilotes Linux et par le noyau pour implémenter le Plug-and-Play. Mais, j'ai commencé à jeter un œil, notamment aux commentaires. Donc, ce guide pratique est encore incomplet. Il devrait expliquer plus en profondeur le « hot swapping », le « hot-plug » et sur le nouveau logiciel PnP du noyau 2.6. Et il ne couvre pas le firewire. Il comporte certainement quelques erreurs (faites-moi savoir où je me trompe). Dans ce guide pratique, j'ai utilisé deux points d'interrogation (??) pour signaler que je n'ai pas vraiment la réponse.

De nouvelles versions du guide pratique Plug-and-Play devraient apparaître fréquemment et seront disponibles à la navigation et/ou en téléchargement sur les sites miroirs du LDP. Pour une liste des sites miroirs, voir http://www.tldp.org/mirrors.html. Différents formats sont disponibles. Si vous voulez seulement vérifier rapidement la date de la dernière version, regardez sur http://www.traduc.org/docs/howto/lecture/Plug-and-Play-HOWTO.html. La version que vous lisez actuellement est la traduction française de la v1.11, de novembre 2004.

Pour un historique des révisions complet, voir le fichier source (dans son format DocBook XML) sur http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Plug-and-Pla y-HOWTO.sgml.gz.

Le Plug-and-Play (PnP) est un système détectant automatiquement les périphériques tels que les disques, les cartes son, les cartes réseau, les modems, etc. Il trouve tous les périphériques du bus PCI et tous les périphériques supportant PnP sur l'ancien bus ISA. Sans PnP, beaucoup de périphériques étaient automatiquement cherchés en utilisant des méthodes non PnP mais n'étaient pas souvent trouvés. PnP fournit un moyen de trouver tous les périphériques supportant PnP. Il réalise aussi une configuration de bas niveau de ces périphériques. Les périphériques non PnP (et les périphériques PnP ayant été correctement configuré avec PnP) peuvent souvent être détectés par des méthodes n'utilisant pas PnP. Le bus PCI moderne a été conçu pour le PnP alors que le vieux bus ISA ne l'a pas été à ses origines mais son support lui a été ajouté plus tard. Donc, souvent, PnP est utilisé pour signifier uniquement PnP pour l'ancien bus ISA. Par exemple, lorsque vous apercevez au démarrage des messages d'isapnp du style : « Plug & Play device », cela signifie seulement qu'il y a un périphérique ISA PnP. Dans ce guide pratique, nous traitons à la fois le PNP du bus ISA et du bus PCI.

Avec le temps, le noyau Linux améliore son support de PnP. Dans la fin du 20è siècle, on pouvait dire que Linux n'était pas un système d'exploitation PnP. Mais l'annonce indique qu'avec la version 2.6 du noyau, Linux est maintenant totalement compatible avec PnP (en supposant que le noyau est construit avec le support de PnP). Bien que le système PnP n'est pas centralisé comme cela peut l'être avec MS Windows (et son registre), le PnP Linux décentralisé semble fonctionner.

Linux conserve la trace des affectations de ressources demandées par les pilotes de périphériques et refuse toute requête s'il estime que cela causerait un conflit. Le noyau fournit aussi des programmes que les pilotes de périphériques peuvent appeler pour effectuer leurs opérations de plug-and-play. Le noyau lit aussi tous les registres de configuration de tous les périphériques PnP et maintient leur tables que les pilotes de périphériques peuvent consulter. Cette table aide les pilotes à trouver leur matériel. Le noyau 2.6 fournit aussi un meilleur support pour le « hot-plug ».

Le BIOS de votre PC travaillera certainement un peu pour le plug-and-play. Donc, si tout fonctionne en harmonie avec PnP, vous pouvez utiliser votre ordinateur sans avoir besoin de tout connaître sur le plug-and-play. Mais, si certains périphériques supportés par Linux ne fonctionnent pas (parce qu'ils n'ont pas été repéré par Linux ou parce qu'ils ont été mal configuré), vous aurez besoin de lire au moins une partie de ce guide pratique. Vous en apprendrez sur le PnP mais aussi sur la façon dont la communication prend place dans un ordinateur. Si vous avez un ordinateur moderne avec un bus PCI mais sans bus ISA, vous pouvez passer les parties sur le bus ISA.

Si vous avez des problèmes avec un périphérique, regardez les messages affichés lors du démarrage (remontez la liste avec Shift-PageUp). Si cela n'affiche pas aussi les messages du lancement, à partir du BIOS, utilisez la touche Pause (voir la section intitulée « Messages de démarrage »).

Vérifiez que vous utilisez le bon pilote pour un périphérique et que ce pilote est trouvé et utilisé. Si le pilote est un module, tapez insmod (en tant qu'utilisateur privilégié) pour voir s'il est chargé (et utilisé). Si ce n'est pas un module, alors il doit être intégré au noyau. Il doit exister un fichier quelque part indiquant quels ont été les pilotes intégrés au noyau (tels que /boot/config-2.4-20 sur une Debian). Quelques fois, un nom de périphérique (tel que /dev/eth0) n'a pas de module associé tant que l'information ne se trouve pas dans le fichier /etc/modules.conf. Par exemple, pour affecter le pilote « tulip » à eth0, ajoutez une ligne comme ceci alias eth0 tulip.

Ce guide pratique ne couvre pas le problème de la recherche et de l'installation de pilotes de périphériques. Peut-être qu'il devrait. Un des problèmes est qu'une carte (ou un autre périphérique physique) peut ne pas dire le type de composants qu'elle utilise. Le nom du pilote correspond souvent au nom de la puce et non pas au nom de la marque. Une façon de commencer la vérification du pilote est de regarder s'il en est question dans la documentation du noyau, dans un autre guide pratique ou plus généralement sur Internet. Attention : de telles documentations peuvent ne plus être à jour.

Les ordinateurs disposant de bus PCI (et sans bus ISA) ont significativement réduit le nombre de points posant problèmes. Pour le bus ISA et le manque de support au niveau noyau pour l'ISA PnP (avant le noyau 2.4), beaucoup de choses posaient problèmes. Rappelez-vouus que, quelque fois les problèmes semblant être relatifs à PnP sont réellement dûs à un matériel défectueux ou à un matériel non conforme aux spécifications PnP.

Si vous ne comprenez pas cette section, lisez la section intitulée « Comment un ordinateur détecte les périphériques (et inversement) ».

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, etc. 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 se faire, PnP alloue les « ressources bus » suivantes à la fois aux pilotes et aux matériels : adresses d'entrée/sortie, plages mémoire, IRQ, canaux DMA (uniquement pour le bus ISA). Ces quatre dernières sont quelques fois appelées des ressources de premier ordre ou simplement des ressources. 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 quelque fois appelé « 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.

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, etc. Dans les anciens temps, la plupart des périphériques étaient des cartes insérées dans des slots 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 ». C'est 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), etc.

Pour rendre tout ceci plus complexe, le pilote du périphérique sélectionné, disons par exemple eth0, peut dépendre du type de carte Ethernet dont vous disposez. Donc, eth0 ne peut pas être associé avec n'importe quel pilote Ethernet. Il doit être associé avec le pilote qui fonctionnera avec votre carte. Si le pilote est un module, certaines de ses associations peuvent être trouvées dans /etc/module.conf (sous le nom d'alias) alors que les autres pourraient résider dans une table interne du noyau. Par exemple, pour une carte Ethernet utilisant le composant tulip, ajoutez alias eth0 tulip dans /etc/modules.conf. de façon à ce que lorsque votre ordinateur cherchera eth0, il trouvera le pilote tulip. D'autres noms de périphériques peuvent être associés avec un pilote standard, donc ce qui vient d'être dit n'est pas habituellement requis.

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 le reste du PC.

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.

Les PC ont 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). Les trois types d'adresses partagent le même bus interne du PC. Mais la présence ou l'absence de voltage sur certains fils dédiés sur le bus du PC indique à quelle plage une adresse appartient : entrées/sorties, mémoire principale (voir la section intitulée « Plages mémoire ») ou configuration. Voir la section intitulée « Détails des adresses » pour plus de détails. Seuls deux de ses trois plages sont utilisées pour le périphérique d'entrées/sorties : entrées/sorties et mémoire principale.

Les périphériques étaient originellement situés dans la plage d'adressage des entrées/sorties mais, aujourd'hui, elles 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é 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. Le processus en deux étapes ressemble au problème de la recherche du numéro de la maison d'une personne dans une rue. Quelqu'un doit afficher le numéro de la maison sur celle-ci de façon à ce qu'on puisse la trouver, et ensuite vous devez obtenir (et écrire) ce numéro pour la trouver. En informatique, le périphérique matériel doit d'abord initialiser l'adresse qu'il utilisera dans un registre spécial (ce qui revient à indiquer le numéro de la maison), et enfin le pilote de périphérique pourra obtenir cette adresse (écrire le numéro dans son carnet d'adresses). Les deux doivent être fait, soit automatiquement par le logiciel soit en entrant les données manuellement dans des fichiers. Des problèmes arrivent quand seulement une des deux étapes est réalisée.

Pour la configuration manuelle de PnP, des personnes font l'erreur de n'en faire qu'une 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.

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, etc.) 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 IRQ du bus PCI ne sont pas donné par un registre d'une carte mais par un composant de routage spécial sur la carte mère.

Beaucoup de périphériques disposent d'une plage mémoire en mémoire principale. C'est quelque fois 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. 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 plage d'adresses utilisée par vos composants ordinaires de RAM bien qu'il ne fasse pas strictement partie de iomem.

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'adressage des entrées/sorties. La carte et le pilote doivent savoir où elle se trouve.

La ROM est différente. 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 est 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 avoir reçu beaucoup d'octets destinés à la mémoire principale et il a besoin de dire au pilote de récupérer ces octets tout de suite et de les transférer en mémoire principale à partir du tampon presque plein. 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é (faisant partie du bus) 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 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 son interruption permet de déterminer 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é. De même, pour le bus PCI, les affectations d'IRQ aux périphériques sont déterminées par un composant programmable de routage. Voir la section intitulée « Détails sur les interruptions » pour savoir comment cela fonctionne.

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. Normalement, le processeur s'occupe des transferts dans 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.

Le bus PCI et l'ancien bus ISA peuvent faire du DMA mais, pour le bus PCI, aucune ressource DMA (canaux) n'est nécessaire. Le DMA sur le bus PCI correspond en fait à la maîtrise du bus mais le terme DMA est souvent utilisé à la place. Il permet aux périphériques de devenir temporairement maître du bus et de transférer les octets pratiquement comme si 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 en ce moment le maître du bus et quel périphérique a démandé la maîtrise du bus. Du coup, il n'y a pas besoin d'allouer des ressources, comme les canaux DMA, pour le bus PCI.

Quand un périphérique du bus ISA veut faire du DMA, il envoie une demande de DMA (DMA-request) en utilisant les fils dédiés, un peu comme une requête d'interruption. Le DMA est gérable en utilisant des interruptions mais cela introduirait des délais, donc il est plus rapide de le faire en utilisant un type spécial d'interruptions connus sous le nom de « demande de DMA ». Comme les interruptions, les demandes de DMA sont numérotées pour identifier le périphérique demandeur. Ce numéro est appelé un canal DMA. Comme les transferts DMA utilisent le bus principal (et seul un peut être lancé à la fois), ils utilisent tous le même canal pour le flot de données, mais le numéro du « canal DMA » sert à identifier qui utilise le « canal ». Des registres matériels présents sur la carte mère enregistrent l'état courant de chaque « canal ». Donc, pour envoyer une requête de DMA, le périphérique doit savoir son numéro de canal DMA, qui doit être enregistré dans un registre spécifique sur le 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) à la fois au périphérique physique et au logiciel le pilotant. Par exemple, un port série utilise seulement deux ressources parmi les quatre possibles : 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). Dans le cas de cavaliers, l'emplacement des cavaliers permet le stockage de la configuration des ressources bus au niveau du périphérique matériel (sur la carte, etc.). Dans le cas de PnP, les données du registre de configuration sont généralement perdues quand le PC est arrêté, donc les données des ressources bus doivent être fournies à chaque périphérique, chaque fois que le PC est allumé.

L'architecture du PC n'apporte qu'un nombre limité d'IRQ, de canaux DMA, d'adresses d'entrées/sorties et de plages mémoires. S'il existait seulement que quelques 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 soucis 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ême adresses, il n'y aurait pas de conflit d'IRQ sur le bus ISA, etc. Chaque pilote devrait être développé avec les adresses uniques, IRQ, etc. codées en dur dans le programme. La vie serait simple.

Mais ce n'est pas le cas. L'augmentation du nombre de périphériques (incluant les nombreux disques, etc.) a tendance à augmenter la fréquence des conflits. En même temps, l'introduction du bus PCI, où deux périphériques et plus peuvent partager la même interruption, a tendance à réduire le nombre de conflits. Le résultat final, dû à la prévalence du PCI, a débouché sur une réduction des conflits car la ressource la plus petite est l'IRQ. Néanmoins, même sur le bus PCI, il est un peu plus efficace d'éviter le partage d'IRQ et il reste toujours des conflits d'adresses même avec le PCI.

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, etc. C'est nécessaire pour éviter tout conflit. 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, il existe un autre problème suite à une erreur en indiquant au pilote de périphérique quelles sont les ressources bus. 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. Mais, avec des ressources configurées par un logiciel PnP, elles ne seront pas toujours identiques et cela va poser problème.

L'allocation de ressources bus, lorsqu'elle est fait correctement, établie 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.

Le terme Plug-and-Play (PnP) a différentes significations. Au sens général, il s'agit de la configuration automatique lorsqu'une personne connecte un périphérique et que celui-ci se configure lui-même. Le sens utilisé dans ce livre est tout autre : PnP signifie la configuration des ressources bus pour PnP (les configurer au niveau des périphériques physiques) et de donner cette information aux pilotes de périphériques. Dans le cas de Linux, il s'agit souvent d'un pilote déterminant la façon dont le bus a initialisé les ressources bus. « PnP » ne signifie parfois que PnP sur le bus ISA donc le message d'isapnp : "No Plug and Play device found" signifie simplement qu'aucun périphérique ISA PnP n'a été trouvé. Les spécifications du PCI standard (inventé avant l'utilisation du terme « PnP ») apportent l'équivalent de PnP au bus PCI.

PnP fait correspondre les périphériques avec leurs pilotes et spécifie leurs canaux de communication (en allouant des ressources bus). Il communique électroniquement avec les registres de configuration situés à l'intérieur des périphériques physiques en utilisant un protocole standardisé. Sur le bus ISA et avant le Plug-and-Play, les ressources bus étaient simplement initialisées au niveau matériel avec des interrupteurs de différentes sortes. Quelque fois, les ressources bus pouvaient être configurées sur le matériel par un programme (généralement sous un système MS) à partir d'une disquette fournie avec le matériel. Cela ressemblait à du PnP mais aucun protocole standardisé n'était utilisé donc il ne s'agissait pas de PnP. Pour Linux, les ressources bus étaient affectées aux pilotes logiciels par des fichiers de configuration (ou autre chose de ce genre) ou en parcourant le bus aux adresses où il s'attendait à trouver le périphérique. Le bus PCI ressemblait au PnP dès le début mais il n'a pas été appelé PnP immédiatement (et ne l'est toujours pas).

Voici comment PnP devrait fonctionner. Le programme de configuration PnP trouve tous les périphériques PnP et demande à chacun les ressources bus dont il a besoin. Ensuite, il vérifie quelles sont les ressources bus qu'il peut affecter (IRQ, etc.). Bien sûr, s'il a réservé des ressources bus utilisées par des périphériques non PnP (s'il les connaît), il ne donne pas celles-là. Il utilise certains critères (ne faisant pas partie des spécifications PnP) pour donner les ressources bus de façon à ce qu'il n'y ait pas de conflit et de façon à ce que tous les périphériques disposent de ce qu'ils ont demandé (si possible). Il indique ensuite indirectement à chaque périphérique physique les ressources bus qui lui ont été assignées et les périphériques se configurent eux-mêmes pour n'utiliser que ces ressources-là. Enfin, les pilotes de périphériques trouvent d'une manière ou d'une autre quelles ressources sont utilisées par leur périphérique et sont donc capables de communiquer avec les périphériques qu'ils contrôlent.

Par exemple, prenons une carte ayant besoin d'une IRQ (d'un numéro d'IRQ) et de 1 Mo de mémoire partagée. Le programme PnP lit cette requête des registres de configuration de la carte. Il lui affecte l'IRQ 5 et 1 Mo d'espace mémoire, commençant à partir de l'adresse 0xe9000000. Le programme PnP lit aussi les informations d'identification de la carte, indiquant ainsi le type de périphérique, son numéro d'identifiant, etc. Ensuite, il informe, directement ou indirectement, le pilote de périphérique, convenable pour ce matériel, de ce qu'il a fait. Si le pilote lui-même gère le PnP, alors il n'est pas nécessaire de trouver un pilote pour le périphérique (car le pilote est déjà en cours d'exécution. Sinon, le bon pilote de périphérique doit être trouvé et la configuration du périphérique doit lui être communiquer.

Ce n'est pas toujours aussi simple car la carte (ou la table de routage pour le PCI) pourrait indiquer qu'elle ne peut utiliser que certains numéros d'IRQ ou que les 1 Mo de mémoire doivent résider dans un certain espace d'adressage. Les détails sont différents pour les bus PCI et ISA, cette dernière étant la plus complexe.

Une façon habituellement utilisée pour allouer des ressources est de commencer avec un périphérique et de lui allouer des ressources bus. Puis de faire la même chose avec le périphérique suivant, etc. Ensuite, si finalement tous les périphériques obtiennent les ressources allouées sans conflit, alors tout va bien. Mais si allouer une ressource requise créait un conflit, alors il serait nécessaire de revenir en arrière et d'essayer de faire quelques changements dans les allocations précédentes de façon à conserver la ressource bus nécessaire. Ceci s'appelle le balancement. Linux ne le fait pas mais MS Windows en est capable dans certains cas. Pour Linux, tout ceci est fait par le BIOS et/ou le noyau et/ou les pilotes de périphériques. Avec Linux, le pilote du périphérique n'obtient pas son allocation finale de ressources tant que le pilote n'est pas lancé, donc une façon d'éviter les conflits est de ne pas lancer un périphérique qui pourrait causer un conflit. Néanmoins, le BIOS alloue fréquemment des ressources au périphérique physique avant que Linux ne soit complètement démarré et le noyau vérifie les périphériques PCI pour les conflits d'adresse au démarrage.

Des raccourcis existent et le logiciel PnP peut les utiliser. Un d'eux est de garder la trace de la façon dont sont assignés les ressources bus lors de la dernière configuration (lorsque l'ordinateur a été utilisé pour la dernière fois) et de réutiliser cette information. MS PnP Windows et les BIOS PnP le font mais le Linux standard ne le fait pas. Windows stocke cette information dans sa base de registres sur le disque dur et un BIOS PnP/PCI le stocke dans une mémoire non volatile de votre PC (mémoire appelée ESCD ; voir la section intitulée « La base de données ESCD du BIOS »). Certains disent que ne pas avoir de registres (ce qui est le cas de Linux) est mieux car, avec Windows, la base de registres peut être corrompue et elle est de toute façon difficile à éditer. Mais PnP sur Linux a aussi des problèmes.

Alors que MS Windows (sauf en ce qui concerne Windows 3.x et NT4) est un système d'exploitation PnP, Linux n'était pas originellement un système d'exploitation PnP mais l'est devenu graduellement. Au début, PnP a fonctionné avec Linux parce qu'un BIOS PnP configurait les ressources bus et que les pilotes de périphériques récupéraient cette information en utilisant des programmes apportés par le noyau Linux. Aujourd'hui, la plupart des pilotes peuvent envoyer des commandes pour réaliser leur propre configuration et n'ont pas besoin de se reposer toujours sur le BIOS. Malheureusement, un pilote pourrait utiliser une ressource bus qu'un autre périphérique aurait besoin plus tard. D'autres pilotes de périphériques enregistrent la dernière configuration dans un fichier de configuration et l'utilisent la prochaine fois que l'ordinateur est allumé.

Si le périphérique physique se rappelle son ancienne configuration, alors il n'y aurait pas de matériel à configurer au prochain démarrage, mais il semble oublier leur configuration lors de l'arrêt. Certains périphériques disposent d'une configuration par défaut (mais pas nécessairement la dernière utilisée). Donc, un périphérique PnP a besoin d'être reconfiguré à chaque fois que le PC est allumé. De la même manière, si un nouveau périphérique est ajouté, alors il a besoin d'être configuré. Allouer des ressources bus pour ce nouveau périphérique peut nécessiter de récupérer des ressources données auparavant à un autre et d'affecter à ce dernier de nouvelles ressources. Actuellement, Linux ne peut pas gérer ce niveau de sophistication (et MS Windows XP pourrait aussi ne pas en être capable).

Quand le PC est lancé la première fois, le BIOS lance son programme pour démarrer le PC (la première étape étant de vérifier le matériel). Si le système d'exploitation est stocké sur disque dur (ce qui est habituellement le cas), alors le BIOS doit disposer de certaines informations sur le disque dur. Si ce disque est PnP, le BIOS peut utiliser des méthodes PnP pour le trouver. De même, pour permettre à l'utilisateur de configurer manuellement le CMOS du BIOS et de répondre aux messages d'erreur lors du démarrage, un écran (et donc une carte vidéo) et un clavier sont aussi requis. Donc, le BIOS doit toujours configurer via PnP les périphériques nécessaires au chargement du système d'exploitation à partir du disque dur.

Une fois que le BIOS a identifié le disque dur, la carte vidéo et le clavier, il est prêt à commencer le démarrage (charger le système d'exploitation en mémoire). Si vous avez indiqué au BIOS que vous disposez d'un système d'exploitation PnP, il devrait commencer le chargement comme indiqué ci-dessus et laisser le système d'exploitation finir la configuration PnP. Autrement, un BIOS-PnP essaiera de configurer le reste des périphériques (mais sans en informer leurs pilotes). Mais les pilotes peuvent toujours trouver ceci en utilisant les fonctions disponibles dans le noyau Linux.

ISA est l'ancien bus des vieux PC compatibles IBM alors que le PCI est un bus conçu par Intel, plus récent et plus rapide. Le bus PCI a été réalisé pour ce qui est appelé de nos jours PnP. Cela rend simple (en comparaison au bus ISA) la recherche de l'assignation des ressources bus PnP aux périphériques physiques. Pour voir ce qui se trouve sur le bus PCI, tapez lspci ou lspci -vv. Vous pouvez aussi lancer scanpci -v mais c'est plus complexe à analyser. Dernière possibilité : regardez le fichier /proc/pci. Les messages de démarrage sur votre écran sont utiles (utilisez shift-PageUp pour aller en arrière et les lire tous). Voir la section intitulée « Messages de démarrage ».

Pour le bus ISA, il existait un problème réel avec l'implémentation de PnP car personne n'avait en tête PnP lorsque ce bus a été conçu et il existe encore moins d'adresses d'entrées/sorties disponibles pour PnP pour envoyer des informations de configuration à un périphérique physique. Du coup, la façon dont PnP a été réalisé pour le bus ISA est très complexe. Des livres entiers ont été écrits à ce sujet. Voir notamment ce livre. Entre autres choses, il requiert que soit assigné par le programme PnP à chaque périphérique PnP un point d'ancrage temporaire pour que tout le monde puisse faire la configuration PnP. Assigner ces « points d'ancrage » est appelé « isolation ». Voir la section intitulée « Isolation ISA » pour des détails complexes.

Au fur et à mesure de la disparition du bus ISA, PnP sera un peu plus facile. Il ne sera pas seulement plus simple de savoir comment le BIOS a configuré le matériel mais il y aura aussi moins de conflits, le PCI pouvant partager des interruptions. Il y aura toujours besoin de faire correspondre un pilote de périphérique à un matériel et il y aura toujours besoin de configurer les périphériques ajoutés lors du lancement du PC. Le sérieux problème des quelques périphériques non supportés par Linux restera présent.

Linux a eu de sérieux problèmes dans le passé pour la gestion de PnP mais la plupart de ces problèmes sont maintenant résolus (vers mi-2004). Linux est parvenu d'un système non PnP à un système PnP non centralisé (chaque périphérique pour lui-même). On peut toujours argumenter sur le fait qu'il n'est toujours pas complètement PnP. À un certain point, il se repose sur les pilotes de périphériques (avec une aide du noyau) et sur le BIOS PnP pour configurer les ressources bus des périphériques.

Lorsque le PC démarre, vous pouvez noter à partir des messages apparaissant sur l'écran que certains pilotes de périphériques trouvent souvent leur périphériques matériels et sont configurés.

Mais le noyau apporte son aide aux pilotes sous la forme de programmes qu'ils peuvent appeler et qui font du PnP. Dans plusieurs cas, le pilote de périphérique, avec l'aide de ces programmes, réalise toute la configuration. Dans d'autres cas, le BIOS peut les avoir configuré et alors le pilote du périphérique peut trouver la façon dont le BIOS a configuré ce périphérique et l'a accepté. Le noyau apporte certaines fonctions aux pilotes pour que ceux-ci puissent trouver leur périphérique, la façon dont il a été configuré, mais aussi des fonctions permettant de modifier cette configuration. Le noyau 2.2 ne pouvait faire ceci que pour le bus PCI mais le noyau 2.4 dispose de cette fonctionnalité pour les bus ISA et PCI (en supposant que les options PnP ont été sélectionnées lors de la compilation du noyau). Ceci ne garantie en rien que tous les pilotes fonctionneront complètement et correctement.

En plus, le noyau permet d'éviter des conflits de ressources en ne permettant pas à deux périphériques d'utiliser les mêmes ressources bus en même temps. Au départ, c'était uniquement pour les IRQ et les DMA mais maintenant c'est aussi valable pour les adresses. Pour le PCI, le noyau vérifie les probables conflits d'adresses lors du démarrage.

Avant le noyau 2.4, le programme indépendant isapnp était souvent lancé pour configurer et/ou obtenir des informations des périphériques PnP du bus ISA. isapnp est encore nécessaire pour les cas où le pilote du périphérique ne gère pas complètement le PnP pour le bus ISA… Il existait au moins un essai rejeté pour faire de Linux un vrai système d'exploitation PnP. Voir http://www.astarte.free-online.co.uk. Bien que développé aux alentours de 1998, il n'a jamais été intégré au noyau (mais aurait certainement dû l'être).

Pour voir quelle aide le noyau peut apporter aux pilotes de périphériques, consultez le répertoire /usr/…/…/Documentation où un des « … » contient le mot « kernel-doc » ou quelque chose d'approchant. Attention : cette documentation a tendance à ne plus être à jour pour avoir les dernières informations donc vous aurez besoin de lire les messages des listes de diffusion des développeurs du noyau et peut-être aussi de lire le code source et les commentaires qu'ils ont écrit. Dans le répertoire de la documentation du noyau, voir pci.txt (« How to Write Linux PCI Drivers », c'est-à-dire « Comment écrire des pilotes PCI pour Linux ») ainsi que le fichier /usr/include/linux/pci.h. Si vous êtes un gourou des pilotes et que vous connaissez la programmation en C, ces fichiers sont écrits d'une telle façon que vous n'apprendrez pas comment écrire un pilote. Mais cela vous donnera une idée des fonctions type PnP disponibles pour les pilotes.

Pour le noyau 2.4, voir isapnp.txt. Pour le noyau 2.6, isapnp.txt est remplacé par pnp.txt qui est totalement différent et gère en plus le bus PCI.

Mais il existe un certain nombre d'autres choses qu'un système d'exploitation PnP devrait mieux gérer :

Comme chaque pilote s'occupe de lui mais pas des autres, un pilote pourrait récupérer les ressources bus nécessaires à d'autres périphériques (et non encore alloués à ceux-ci par le noyau). Donc un noyau Linux PnP plus perfectionné serait bien mieux, un noyau qui pourrait s'occuper de l'allocation une fois toutes les requêtes envoyées. Une autre alternative serait d'essayer de réallouer les ressources déjà affectées si un pilote n'obtient pas toutes les ressources qu'il a demandé.

Le problème de la « rareté des ressources bus » devient de moins en moins un problème pour deux raisons : la première est que le bus PCI est en train de remplacer le bus ISA. Le bus PCI n'a pas ce type de problème pour les IRQ car celles-ci peuvent être partagées (bien que ce partage rend le système un peu moins efficace). De plus, le PCI n'utilise pas les ressources DMA (bien qu'il dispose d'un équivalent sans avoir besoin des ressources).

La deuxième raison est que plus d'espace d'adressage est disponible pour les entrées/sorties des périphériques. Alors que l'espace d'adressage conventionnel du bus ISA était limité à 64 Ko, le bus PCI dispose de 4 Go. Comme plus de périphériques physiques utilisent les adresses en mémoire principale au lieu de l'espace d'adressage des entrées/sorties, il existe toujours un peu de place disponible, y compris sur le bus ISA. Sur les PC 32 bits, il y a un espace d'adressage de 4 Go en mémoire principale et la plupart de ces ressources bus est disponible pour les entrées/sorties des périphériques (à moins que vous ayez 4 Go de mémoire principale installée).

Quelque soit votre réponse au BIOS, le BIOS PnP configurera via PnP le disque dur, le lecteur de disquette, la carte vidéo et le clavier pour rendre le système démarrable. Si vous dites avoir un système d'exploitation PnP, il laissera la fin de la configuration au système d'exploitation (ou aux pilotes de périphériques). Si vous dîtes ne pas avoir de système d'exploitation PnP, alors le BIOS devra tout configurer.

Comment répondre à cette question de votre BIOS ? Si vous avez au moins un noyau 2.4, vous pourriez répondre ce que vous voulez et Linux fonctionnera habituellement correctement. Mais si Linux ne peut pas gérer quelque chose que le BIOS peut (par exemple le bus LPC ??), alors vous devriez dire qu'il ne s'agit pas d'un système d'exploitation PnP. Même si vous avez Windows 2000 ou XP sur le même PC, cela devrait fonctionner de tout façon tout simplement parce que Windows et Linux sont tous les deux supposément des systèmes d'exploitation PnP et que si le système d'exploitation est PnP, il devrait être capable de gérer le cas où le BIOS a tout configuré lui-même (si vous avez répondu que le système d'exploitation n'est pas PnP). Mais, je continue à suggèrer de répondre qu'il n'est pas PnP sauf si une raison valable vous oblige de faire autrement.

Les BIOS modernes vous permettent d'allouer manuellement des resources, principalement des IRQ. Il existe normalement une option pour configurer l'allocation à « auto » de façon à ce que le BIOS décide de l'allocation des ressources. « Auto » est souvent un bon choix sauf si vous avez d'anciennes cartes ISA propriétaires non PnP.

Si vous avez de telles cartes non PnP, alors il pourrait être important de réserver les ressources (telles que les IRQ) pour celles-ci dans le BIOS. Sinon, le BIOS pourrait utiliser ces ressources pour d'autres périphériques et créer ainsi des conflits. Une exception concerne quelques périphériques propriétaires communs, comme les ports parallèle et séries, les disques durs. Le BIOS pourrait les trouver (jetez un œil à l'écran au démarrage) pour que vous n'ayez pas besoin de réserver les ressources pour eux. Si vous avez utilisé Windows sur votre PC, Windows pourrait déjà avoir renseigné le BIOS en utilisant l'outil ICU (ou un identique) sous Windows.

Pour le PCI, le BIOS devrait aussi vous permettre d'affecter les IRQ aux emplacements de cartes 1, 2, 3, 4, etc. Si vous le faites, vous devez savoir les emplacements où se trouvent les cartes. En fait, chaque emplacement dispose de quatre IRQ PCI : A, B, C et D. Si le menu du BIOS ne vous dit pas laquelle (A, B, C, D) est affectée à un numéro d'IRQ, il est probable qu'il affecte seulement le numéro d'IRQ à l'IRQ PCI A. Mais, beaucoup de cartes utilisent seulement l'IRQ A donc il s'agit surtout d'affecter une IRQ à un emplacement. Voir la section intitulée « Interruptions PCI ».

C'est aussi un peu risqué. Ceci va écraser les données du BIOS contenues dans l'ESCD indiquant la façon dont vos périphériques PnP ont été configuré et comment les périphériques non PnP ont été configuré manuellement. Ne faites jamais ceci à moins que vous ne soyez convaincu que la base de données est mauvaise et a besoin d'être reconstruite. Il était indiqué quelque part que vous deviez faire ceci seulement lorsque vous n'arrivez plus à démarrer. Si le BIOS perd les données sur les périphériques ISA non PnP, alors vous devrez relancer ICA une nouvelle fois sous DOS/Windows pour ré-enregistrer les données.

De nos jours, la plupart des nouvelles cartes internes sont Plug-and-Play. La configuration des ressources bus devraient être dans la plupart des cas entièrement automatique. Si un périphérique ne fonctionne pas, vérifiez s'il a été détecté, par exemple en redémarrant. Si le pilote de périphérique ne peut pas configurer les ressources, alors probablement une ou plus des méthodes du 2.6 le feront :

N'importe lequel configurera les ressources bus au niveau matériel mais seul le premier (voire le second) indiquera au pilote ce qui a été fait. Comment le pilote est informé dépend du pilote. Vous pouvez avoir besoin de faire quelque chose pour l'informer. Voir la section intitulée « Indiquer au pilote la configuration ».

La plupart des pilotes de périphériques (avec l'aide de fonctions du noyau) utilisera des méthodes PnP pour configurer les ressources bus du matériel mais seulement pour le périphérique qu'ils contrôlent. Comme le pilote a réalisé la configuration, il est évident qu'il connaît cette configuration et il n'est donc pas nécessaire de lui donner cette information. C'est de manière évidente la façon la plus facile de le faire car vous n'avez rien à faire si le pilote fait tout. En fait, le BIOS a souvent réalisé la configuration avant que Linux ne soit lancé. Dans ce cas, le pilote, utilisant des méthodes PnP, découvre que le BIOS a tout fait et accepte souvent cela (ou dans certains cas, le refait différemment). Dans tous les cas, le pilote a été configuré.

Si vous avez un matériel datant d'avant l'ISA PnP, le logiciel PnP Linux pourrait ne pas le savoir et pourrait ne pas connaître les ressources bus qu'il réclame. Donc, il pourrait allouer de façon erronée des ressources dont cet ancien matériel a besoin à un autre périphérique. Le résultat est un conflit de ressources mais il existe un moyen de l'éviter. Vous pouvez réserver les ressources dont cette ancienne carte ISA a besoin en donnant les arguments au BIOS (habituellement), au module isa-pnp ou au noyau (si le support de PnP est intégré dans le noyau). Par exemple, pour réserver l'IRQ 5, donnez cet argument au module isa-pnp (ou au noyau) : isapnp_reserve_irq=5. Voir le Guide pratique sur l'invite de démarrage (BootPrompt-HOWTO). Au lieu de ..._irq, il existe aussi _io, _dma et _mem. Est-ce assez intelligent pour empêcher un périphérique PCI d'utiliser de telles ressources réservées ??

Pour les périphériques PCI, la plupart des pilotes configureront PnP. Malheureusement, un pilote peut récupérer des ressources bus nécessaires à d'autres périphériques (mais non alloués à eux par le noyau). Donc, un noyau Linux PnP plus perfectionné serait meilleur là où le noyau fait l'allocation pour toutes les demandes envoyées. Voir la section intitulée « Comment Linux gère-t'il le PnP ».

Depuis le noyau 2.6, il existe une nouvelle façon pour que l'utilisateur configure les ressources grâce au répertoire /sys. Mais, jusqu'à août 2004, il ne peut pas être utilisé pour une configuration dans la plupart des cas. Voir la section intitulée « Le répertoire /sys ».

Les périphériques PCI sont PnP à la base donc cela ne peut pas être désactivé. Mais quelques périphériques ISA ont des options pour désactiver PnP par l'intermédiaire de cavaliers ou en lançant un programme Windows fourni avec le périphérique (configuration logicielle). Si le pilote du périphérique ne peut pas le configurer, ceci évitera la tâche probablement compliqué de la configuration PnP. N'oubliez pas de dire au BIOS que ces ressources bus sont réservées. Mais comme le support de Linux pour le PnP a été amélioré, vous ne voulez généralement pas désactiver PnP. Voici quelques arguments pour lesquels vous ne voudrez pas désactiver PnP :

Une fois vos périphériques configurés sans PnP, ils ne peuvent plus être configuré par un logiciel PnP ou par un BIOS PnP (jusqu'à ce que vous changiez les cavaliers et/ou utilisiez le logiciel de configuration Dos/Windows).

Le programme isapnp est utilisé uniquement pour les périphériques PnP du bus ISA (donc non PCI). Il était vraiment nécessaire avant les noyaux 2.4. Avec le noyau 2.4, qui a apporté des fonctionnalités permettant aux pilotes de gérer le PnP sur le bus ISA, le programme isapnp devient moins important. De plus, le BIOS pourrait configurer ISA PnP de manière satisfaisante. Mais, le module isa-pnp (ou l'équivalent intégré au noyau) est déjà très satisfaisant car de nombreux pilotes de périphériques ISA l'appellent pour configurer les ressources du bus. Avant le noyau 2.6, cela résultait en un « fichier » /proc/isapnp pouvant être utilisé pour configurer manuellement (voir isapnp.txt dans la documentation du noyau).

Dans certains cas, les distributions Linux ont été configuré pour lancer isapnp automatiquement au lancement. Il est toujours utilisé en 2004 mais il n'est pas réellement nécessaire si les pilotes de périphériques fonctionnent bien. Si vous avez besoin de le configurer vous-même, la grande partie de la documentation d'isapnp est difficile à comprendre sauf si vous possédez des notions de base de PnP. Ce guide pratique devrait vous aider à le comprendre, ainsi que la FAQ qui accompagne isapnp. Lancer le programme isapnp au démarrage vous permettra de configurer ces périphériques suivant les valeurs spécifiées dans /etc/isapnp.conf. Il est possible de créer ce fichier de configuration automatiquement mais vous devrez alors l'éditer manuellement pour choisir entre les différentes options. Puis pour que le pilote connaisse ces ressources, vous avez souvent besoin de les spécifier en tant que paramètres pour les modules appropriés (pilotes). Ceci se fait avec des fichiers de configuration, généralement dans le répertoire /etc. Cherchez-y des fichiers nommés mod*, etc. Si le pilote est intégré au noyau, alors ils pourraient parfois être donnés comme paramètre du noyau. Voir le guide pratique des options de démarrage.

Avec isapnp, il existait un risque qu'un pilote de périphérique, intégré au noyau, soit lancé trop tôt, avant qu'isapnp n'ait pu configurer les adresses, et cætera au niveau matériel. Ceci aurait pour résultat que le pilote de périphérique ne sera plus capable de trouver le périphérique. Le pilote essaie la bonne adresse mais cette adresse n'est pas configurée au niveau matériel. Cela est-il toujours un problème ??

Si votre distribution Linux a automatiquement installé isapnptools, isapnp est probablement lancé au démarrage. Dans ce cas, il ne vous reste qu'à éditer /etc/isapnp.conf suivant man isapnp.conf. Notez que cela revient à configurer manuellement PnP car vous ferez les décisions sur la façon de configurer lors de l'édition du fichier de configuration.

Si le fichier de configuration est mauvais ou n'existe pas, vous pouvez utiliser le programme pnpdump pour vous aider à créer le fichier de configuration. Il crée pour vous un fichier de configuration mais vous devrez l'éditer avec intelligence avant de l'utiliser. Il contient quelques commentaires pour vous aider. Alors que le BIOS pourrait aussi avoir configuré les périphériques ISA (si vous lui avez dit que vous ne disposez pas de système d'exploitation PnP), isapnp le refera.

La terminologie utilisée dans le fichier /etc/isapnp.conf peut sembler étrange au début. Par exemple, pour une adresse d'entrée/sortie 0x3e8, vous pourriez voir « (IO 0 (BASE 0x3e8)) » à la place. « IO 0 » veut dire qu'il s'agit de la première plage d'adresses que ce périphérique utilise. Une autre façon d'exprimer ceci serait : « IO[0] = 0x3e8 » mais isapnp ne le fait pas de cette façon. « IO 1 » voudrait dire qu'il s'agit de la deuxième plage d'adresse utilisée par ce périphérique, et cætera. « INT 0 » a une signification similaire mais pour les IRQ (interruptions). Une carte simple peut contenir plusieurs périphériques physiques mais l'explication ci-dessus était seulement pour un des périphériques.

Le paquetage des utilitaires PCI (pciutils, quelque fois appelé « pcitools ») vous laissera configurer manuellement via PnP le bus PCI. lspci ou scanpci (Xwindows) liste les ressources bus alors que setpci enregistre les allocations des périphériques physiques. Il semble que setpci soit principalement utilisé dans des scripts et en fait, vous aurez besoin de connaître le détail des registres de configuration du PCI pour pouvoir l'utiliser. Ce thème n'est pas expliqué ici, et pas plus dans la page de manuel de setpci.

Les gens l'ont utilisé pour configurer les périphériques PCI dont le pilote a échoué dans cette action. Un exemple est disponible dans le guide pratique sur les modems et le guide pratique sur les ports séries dans la sous-section « PCI : Activer un port désactivé ». Néanmoins, activer un périphérique n'est d'aucune utilité si vous n'avez pas de pilote fonctionnel pour ce périphérique.

Cette méthode utilise MS Windows pour configurer et devrait être utilisé seulement si tout le reste échoue. Si vous avez Windows 9x (ou 2k) sur le même PC, alors lancez simplement Windows et laissez-le configurer PnP. Puis lancez Linux à partir de Windows (ou DOS) en utilisant, par exemple, loadlin.exe. Mais il peut y avoir un problème avec les IRQ pour les périphériques PCI. Quand Windows s'arrête (sans messages) pour laisser la place à Linux, il pourrait écraser l'IRQ (en y mettant 0) qui est stocké dans un des registres de configuration du périphérique PCI. Linux se plaindra de trouver une IRQ 0.

Ce qu'on vient d'aborder arrive lorsque vous lancez Linux en utilisant un raccourci (fichier PIF). Mais un moyen de contourner ce problème est connu si vous utilisez toujours le raccourci PIF. Un raccourci est en quelque sorte l'équivalent du lien symbolique sous Linux, mais il est en fait plus que ça car il est configurable. Pour lancer Linux, à partir de DOS, vous créez un fichier batch (script) qui lance Linux. (Le programme qui lance Linux est dans le package appelé loadlin.) Ensuite, créez un raccourci PIF vers ce fichier batch et allez dans la fenêtre des propriétés du raccourci. Sélectionnez « Avancé », puis vérifiez que le « mode MS-DOS » est bien coché.

Maintenant, voici une astuce empêchant de mettre à zéro les IRQ PCI. Cochez « Spécifier une nouvelle configuration MS-DOS ». Ensuite, soit vous acceptez la configuration par défaut qui vous est proposée soit vous cliquez sur « Configuration » pour la modifier. Maintenant, lorsque vous lancerez Linux en cliquant sur le raccourci, des nouveaux fichiers de configurations (config.sys et autoexec.bat) seront créés pour votre nouvelle configuration.

Les anciens fichiers sont enregistrés comme Config.wos et Autoexec.wos. Une fois que vous avez terminé d'utiliser Linux et que vous avez arrêté votre PC, vous aurez encore besoin de ces fichiers pour pouvoir lancer DIS la prochaine fois que vous démarrerez votre PC. Vous devez vous assurer que les noms redeviennent *.sys et *.bat. Lorsque vous quittez Windows/DOS pour aller sous Linux, Windows s'attend que, une fois que vous avez fini avec Linux, vous retourniez à Windows pour que celui-ci puisse restaurer ces fichiers avec leur noms originaux. Mais ceci n'arrivera pas car lorsque vous quitterez Linux, vous éteindrez votre PC et ne retournerez pas sous Windows. Donc, comment renommer ces fichiers ? C'est facile, placez ces commandes dans votre fichier batch de lancement de Linux pour qu'il renomme les fichiers. Mettez ces commandes de renommage dans votre fichier batch juste avant la ligne qui charge Linux.

De la même façon, il a été rapporté que vous devez cliquer sur l'onglet « Général » (de la fenêtre « Propriétés » de votre raccourci) et cochez « Lecture seule ». Sinon, Windows pourrait remettre à zéro les « Paramétrages avancées » en « Utilisez la configuration MS-DOS courante » et les IRQ PCI se retrouveraient à zéro. Comme Windows efface les IRQ lorsque vous utilisez la configuration MS-DOS courante mais il n'efface pas une nouvelle configuration (qui peut configurer tout de manière identique à l'ancienne configuration). Windows ne semble pas très cohérent.

Un pilote moderne trouvera pour un périphérique la configuration des ressources bus sans que vous ayez besoin de lui dire quoi que ce soit. Il pourrait même enregistrer les ressources bus au niveau matériel en utilisant des méthodes PnP. Certains périphériques ont plus d'une façon pour trouver comment leur périphérique physique est configuré. Dans le pire des cas, vous devez coder en dur les ressources bus dans le noyau (ou un module) et recompiler.

En un juste milieu, il existe des cas tels que le lancement d'un programme pour donner les informations des ressources bus au pilote ou pour mettre les informations dans un fichier de configuration. Dans certains cas, le pilote peut chercher le périphérique aux adresses où il suppose qu'il réside (mais il ne trouvera jamais un périphérique PnP s'il n'a pas été activé par des méthodes PnP). Il peut même essayer de tester différentes IRQ pour voir laquelle fonctionne. Il peut, ou non, le faire automatiquement.

Dans d'autres cas, le pilote peut utiliser des méthodes PnP pour trouver le périphérique et la façon dont les ressources bus ont été configuré par le BIOS, etc. mais ne les modifiera pas. Il peut aussi regarder dans certains des « fichiers » du répertoire /proc.

Il peut aussi dire « manuellement » au pilote les ressources bus qu'il doit utiliser. Vous donnez ces ressources bus en tant que paramètre pour le noyau ou pour un module chargeable. Si le pilote est intégré au noyau, vous passez les paramètres au noyau via l'invite du démarrage. Voir le Guide pratique sur l'invite de démarrage (BootPrompt-HOWTO) pour la description de quelques ressources bus et autres paramètres. Une fois que vous savez quels paramètres donner au noyau, vous pouvez les enregistrer dans un fichier de configuration du chargeur. Par exemple, mettez append="…" dans le fichier lilo.conf puis lancez lilo pour qu'il mette à jour les informations de lancement.

Si le pilote est chargé comme un module, dans plusieurs cas, le module trouvera les ressources bus nécessaires et les enregistrera dans le périphérique. Dans les autres cas (généralement pour les anciens PC), vous pouvez avoir besoin de donner les ressources bus comme paramètres du module. Les paramètres d'un module peuvent être spécifiés dans /etc/modules.conf. Ce sont généralement des outils utilisé pour modifier ce fichier et qui sont dépendant de la distribution. Les commentaires inclus dans ce fichier devraient vous aider sur la façon de le modifier. De même, tout module que vous placez dans /etc/modules se verra charger avec ses paramètres.

Bien qu'il ait une grande non-uniformité sur la façon dont les pilotes trouvent leur ressources bus, le but final est le même. Si vous avez des problèmes avec un pilote, vous pouvez avoir besoin de regarder la documentation du pilote (vérifier la documentation du noyau). Quelques exemples brefs de pilotes sont présentés dans les sections suivantes :

Pour les ports séries PCI (et, pour les nouveaux noyaux 2.4, pour ISA), le pilote série détecte le type de port série et le configure via PnP. Malheureusement, quelques ports série PCI ne sont pas encore supportés.

Pour le pilote du port série ISA standard avec les anciennes versions du noyau et pour le pilote série (ne faisant pas partie des cartes multiports), vous utilisez setserial pour informer le pilote. Utiliser setserial est aussi nécessaire pour les ports série non PnP. setserial est souvent lancé à partir d'un fichier de démarrage. Dans les versions récentes, il existe un fichier /etc/serial.conf que vous « éditez » en lançant simplement la commande setserial de façon ordinaire et ce que vous configurez avec setserial est sauvegardé dans le fichier de configuration serial.conf. Le fichier serial.conf devrait être consulté lorsque la commande setserial est lancé à partir d'un fichier de démarrage. Votre distribution peut, ou non, avoir configuré ceci pour vous.

Il existe deux façons d'utiliser setserial suivant les options que vous lui donnez. Une possibilité est de dire manuellement au pilote la configuration. L'autre méthode est de tester une adresse donnée et d'indiquer si un port série existe à cet endroit. Il peut aussi tester cette adresse et essayer de détecter l'IRQ utilisée par ce port. Le pilote lance quelque chose comme setserial au lancement mais il ne teste pas les IRQ, il affecte seulement l'IRQ standard qui peut être mauvaise. Il teste l'existence d'un port. Voir le Guide pratique sur la programmation des ports série pour plus de détails.

Une fois que vous avez trouvé votre matériel, le même programme qui l'a trouvé vous indique normalement comment il est configuré. Donc, trouver comment un matériel est configuré revient habituellement à trouver le matériel.

Ici, « configuration » correspond à l'assignation des ressources bus PnP (adresses, IRQ et DMA). Pour chaque périphérique, il existe deux parties à cette question de configuration :

Chaque partie devrait avoir la même réponse (la même configuration). La configuration du périphérique physique et de son pilote devrait être évidemment la même (et l'est habituellement). Mais les choses ne fonctionnent pas toujours bien et c'est pourquoi il existe une différence. Ceci veut dire que le pilote dispose d'une mauvaise information sur la configuration actuelle du matériel. Ceci sent les problèmes. Si le logiciel que vous utilisez ne vous dit pas exactement ce qui ne va pas (ou ne configure pas automatiquement correctement), alors vous avez besoin de chercher comment vos périphériques physiques et vos pilotes sont configurés. Alors que les pilotes de périphériques Linux devraient tout vous dire, dans certains cas, il n'est pas facile de déterminer ce qui a été enregistré au niveau matériel.

Un autre problème est que lors de la visualisation des messages de configuration à l'écran, vous devez savoir si la configuration affichée est celle du pilote, du périphérique physique ou des deux. Si le pilote de périphérique a soit enregistré la configuration soit vérifié le matériel, alors le pilote devrait avoir les bonnes informations.

Mais, quelque fois, le pilote a obtenu des ressources incorrectes par un script ou un fichier de configuration, par des paramètres de ressources incorrectes données à un module, ou peut-être même que la configuration ne lui a pas été fourni complètement et essaie d'utiliser par défaut des ressources incorrectes. Par exemple, quelqu'un peut utiliser setserial pour dire au pilote de périphérique une configuration des ressources incorrecte et le pilote les acceptera sans broncher. Mais le port série ne fonctionne pas bien (s'il fonctionne tout court).

Un problème habituel est que le logiciel ne détecte pas votre périphérique et/ou ne détermine pas le bon pilote pour celui-ci. Pour les périphériques PnP, les détecter est facile avec un logiciel PnP sauf pour le cas inhabituel où le matériel a été désactivé. Le BIOS peut parfois être initialisé pour désactiver les périphériques PnP ou un cavalier/interrupteur sur le périphérique physique lui-même pourrait le désactiver. Dans ce cas, le matériel ne peut pas être détecté du tout jusqu'à ce que vous re-configuriez le BIOS ou que vous changiez le cavalier/interrupteur.

Comme le bus PCI est intrinsèquement PnP, il n'y a pas de périphériques cachés. Même si les périphériques PnP sont faciles à trouver avec les méthodes PnP, si le pilote n'utilise pas les méthodes PnP mais utilise l'ancienne méthode de recherche aux adresses supposées, ils pourraient ne pas être trouvés. Ceci est dû au fait que, avant que les ressources bus aient été initialisées (par le BIOS ou Linux), le périphérique pourrait ne pas avoir d'adresses du tout, donc parcourir les adresses habituelles n'apportera rien. Pour l'ancien bus ISA, quelques-uns des périphériques pourraient être non PnP et, de ce fait, les anciennes méthodes pourraient fonctionner. Donc, de nombreux pilotes continuent à parcourir les adresses habituelles en plus d'utiliser les méthodes PnP (parcours PnP, quelque fois appelé simplement parcours).

Façons de détecter des périphériques matériels (et leur configurations)  : (suivre le lien pour plus de détails)

Des informations significatives sur la configuration peuvent être obtenues en lisant les messages affichés par le BIOS et par Linux lors du démarrage de l'ordinateur. Ces messages disparaissent souvent trop rapidement pour être lus mais, une fois le défilement terminé, tapez Majuscule-Page Suivante plusieurs fois pour revenir en arrière. Pour aller en avant, faites Majuscule-Page Précédente. Utilisez dmesg à la console à n'importe quel moment pour afficher seulement les messages du noyau. Vous ne verrez pas certains messages les plus importants provenant généralement du BIOS. Les messages affichés par Linux peuvent parfois n'afficher que ce que le pilote de périphérique croit être configuré, peut-être à cause d'un mauvais fichier de configuration. Vérifier les fichiers de traces dans /var/log peut être utile.

Pour le bus PCI, la notation 00:1a:0 signifie le bus PCI 00 (le bus PCI principal), la carte PCI (ou le composant) 1a et la fonction 0 (le premier périphérique) sur la carte ou le composant. Le deuxième périphérique sur la carte (ou sur le composant) devrait être 00:08:1.

Les messages du BIOS s'affichent en premier et montrent la configuration du matériel à ce moment, mais isapnp, ou les utilitaires PCI, voire les pilotes de périphériques peuvent le changer plus tard. Dans certains cas, il n'affiche pas les périphériques que le BIOS n'a pas configuré.

Si les messages du BIOS ne s'affichent pas en revenant au début des messages du BIOS avec Majuscule-Page Suivante, essayez de mettre en pause lorsqu'ils apparaissent, en utilisant la touche Pause dès que les premiers mots apparaissent. Appuyez sur n'importe quelle touche pour continuer. Il est souvent difficile d'appuyez sur Pause exactement au bon moment. Assurez-vous d'appuyer continuellement sur la touche Shift avant d'appuyer sur Pause car Pause est une touche nécessitant l'utilisation de Shift. Si vous n'avez pas réussi, appuyez sur Ctrl-Alt-Del au lancement de Linux pour le relancer et essayer de nouveau. Une fois que les messages de Linux commencent à être visible, il est trop tard pour utiliser Pause car cela ne gèlera pas les messages de Linux.

Pour initialiser des éléments du BIOS comme les IRQ réservés au matériel propriétaire, aux adresses des ports série, etc. vous aurez besoin d'entrer dans les menus de configuration du BIOS (CMOS) au lancement. Chaque marque de BIOS a différentes touches pour se faire. Il existe des listes sur Internet. Quelque fois en gelant l'affichage des messages du BIOS ou en regardant l'écran, la touche que vous devez appuyer sera indiquée dans un message tel que « Press DEL for setup » (« Appuyez sur DEL pour la configuration »). Mais il pourrait disparaître si rapidement que vous ne le verrez pas. Bien sûr, vous ne modifiez rien dans le BIOS que vous ne comprenez pas. Le cas contraire, votre PC pourrait être désactivé.

Les messages du BIOS au démarrage vous indique ce que fut la configuration du matériel. La configuration actuelle pourrait toujours être la même que ce qu'a fait le BIOS et que Linux devrait être accepter si c'est bon. Les messages de Linux pourraient provenir des pilotes utilisant les fonctions PnP du noyau pour inspecter et/ou configurer les ressources bus. Cela devrait être correct mais attention aux messages qui affichent seulement ce que le pilote a lu de son fichier de configuration. Cela pourrait être faux. Bien sûr, si le périphérique fonctionne bien, alors il est configuré probablement de la même façon par le pilote.

Depuis le noyau 2.6, il existe aussi un répertoire /sys en plus du répertoire /proc. Ces répertoires sont utiles pour récupérer les configurations des ressources et périphériques. La plupart de ce contenu est assez complexe, spécialement dans la partie /sys. Mieux vaut utiliser des programmes qui récupèreront l'information de ces répertoires et les afficheront dans une forme plus facile à appréhender. Un exemple est lspci. Beaucoup de fichiers concernent les ressources bus. Seuls quelques uns sont mentionnés ici.

/proc/ioports affiche les adresses d'entrées/sorties qu'utilisent les périphériques actifs (ou essaient d'utiliser si elles sont erronées). Elles pourraient ne pas être initialisées ainsi au niveau matériel. /proc/interrupts affiche toutes les interruptions en cours d'utilisation. Un grand nombre d'interruptions allouées à des pilotes ne s'affichent pas ici car elles ne sont pas en cours d'utilisation. Par exemple, même si votre lecteur de disquette contient une disquette et qu'il est prêt à être utilisé, son interruption ne s'affichera pas ici sauf s'il est en cours d'utilisation. Encore une fois, le simple fait qu'une interruption s'affiche ici ne signifie pas qu'elle existera toujours au niveau matériel. Une preuve qu'elle n'existe pas pourra être qu'aucune interruption n'a été lancé par cette interruption. Même si elle affiche que quelques interruptions ont été lancées, il n'y a aucune garantie qu'elles proviennent du périphérique affiché. Cela pourrait être un autre périphérique, actuellement inutilisé. Un périphérique non utilisé (par le noyau) pourrait avoir lancé des interruptions.

À partir du noyau 2.6, il existe un nouveau répertoire /sys pour la configuration de PnP. Il s'agit d'un système de fichiers de type sysfs et c'est un équivalent du système de fichiers /proc car les « fichiers » représentent une information de la mémoire du noyau et non pas un vrai fichier de votre disque dur. Cependant, il n'est pas aussi utile que le système de fichiers /proc. Au début (pour les noyaux 2.5), il s'appellait le « système de fichiers des pilotes » et avait comme type « driverfs ».

Dans ce système de fichiers, chaque périphérique existant sur votre système a son propre répertoire contenant des fichiers spécifiant les ressources qui lui sont affectées. Ces répertoires ont des noms comme 0000:00:12.0@ ou 00:06@. Quels sont ces périphériques ? Le premier est une carte PCI dans l'emplacement 12 de votre PC. L'emplacement pourrait être appelé PCI2 dans votre PC (2 au lieu de 12) tout simplement parce que les emplacements ayant des numéros fiables sont utilisés par les emplacements intégrés à la carte mère et n'utilisent pas les emplacements physiques. Dans cet exemple, les emplacements 1 à 10 seraient intégrés alors que les emplacements 11 à 14 seraient appelés de 1 à 4. En exécutant lspci, vous connaîtrez la correspondance entre les numéros (comme 0000:00:12.0) et les noms (identique à l'interface IDE). Utilisez la commande lspci -vv.

Alors, qu'est-ce que 00:06 ? C'est une carte ISA (ou un périphérique intégré) mais ce n'est pas l'emplacement 6 du bus ISA (contrairement au numérotage PCI). Quand une recherche est faite pour les périphériques PnP ISA, il a été le sixième découvert. Plus précisément, il était le septième trouvé car il existe un périphérique numéroté 00:00. Donc, comment les identifier ? Vous pouvez lancer « cat */* » et afficher tous les fichiers pour tous les périphériques mais même à ce moment-là vous ne verrez pas les noms des périphériques (mais vous verrez l'information qui vous permettra de l'identifier). Cet problème sera corrigé dans le futur.

Non seulement ces fichiers apportent des informations sur la configuration des ressources du bus (d'une manière un peu cryptée) et sur les pilotes (dans les répertoires « drivers ») mais, dans le futur, vous devriez être capable de les utiliser pour modifier la configuration des ressources. Actuellement (août 2004), vous ne pouvez pas configurer le bus PCI avec cela. Une sérieuse limitation est qu'avec le « modèle de pilote » actuel, vous ne pouvez pas changer la ressource d'un périphérique qui a été affecté à un pilote, ce qui signifie généralement que vous aurez besoin de décharger le module du pilote pour pouvoir l'utiliser. Si le pilote est intégré, il n'y a aucun espoir. Ces sérieuses limitations seront éliminées dans le futur avec un peu de chance. Dans la documentation du noyau se trouve un fichier pnp.txt indiquant comment réaliser la configuration. À la date d'août 2004, il était obsolète mais l'auteur travaille sur une mise à jour. Utiliser le répertoire /sys pour configurer les ressources est connue comme l'« interface utilisateur pour le Plug and Play de Linux ».

L'autre partie de « Linux Plug and Play » est l'interface noyau utilisée par les pilotes de périphériques. Elle a beaucoup changé depuis le début du noyau 2.6 mais la plupart des pilotes utilisent toujours l'ancienne interface (août 2004). Il est aussi possible pour les pilotes (ou vous) d'utiliser l'interface utilisateur qui a besoin d'améliorations.

Il est facile de trouver quelles ressources bus ont été assignées aux périphériques du bus PCI avec les commandes lspci et/ou scanpci ou jetez un œil sur /proc/pci. L'option -v vous donnera plus de détails. /proc/buspci/devices donne un affichage pratiquement incompréhensible, donc évitez-le. Notez que les IRQ dans /proc/pci sont en hexadécimal.

Dans la plupart des cas pour le PCI, vous verrez seulement comment le matériel est maintenant configuré et pas quelles ressources sont nécessaires. Dans certains cas, vous verrez seulement l'adresse de base (le début des plages d'adresses) mais pas celle de fin. Si vous disposez de l'espace complet, alors vous pourrez déterminer combien d'octets de ressources sont nécessaires.

Pour les cartes du bus ISA, ce n'est pas aussi simple que pour le bus PCI qui est conçu pour le PnP. Les cartes ISA récentes sont PnP contrairement aux anciennes. De même, certaines cartes PnP ont leur partie PnP désactivée par des logiciels spéciaux fonctionnant que sous MS Windows. Les cartes non PnP sont configurées avec des cavaliers sur la carte ou par des logiciels sous MS Windows.

Si c'est une carte PnP, vous pouvez essayer pnpdump --dumpregs mais ce n'est pas une certitude. Le résultat peut sembler crypter mais il peut être déchiffré. Ne confondez pas les adresses de port de lecture que pnpdump utilise pour communiquer avec les cartes PnP avec l'adresse d'entrées/sorties du périphérique trouvé. Elles ne sont pas identiques.

LPC est une interface type bus souvent utilisée sur les portables mais aussi sur certaines machine sde bureau. Pour savoir si vous disposez d'un bus LPC, saisissez la commande lspci et cherchez quelque chose ressemblant à ceci : « ISA Bridge ... LPC Interface Controller ». Vous voyez « ISA Bridge » (Pont ISA) car le bus LPC pourrait être considéré comme faisant partie de la catégorie ISA des bus mais, attention, LPC n'est pas ISA.

Le bus ISA était lent mais a été généralement remplace par le bus rapide PCI. Mais pour les périphériques lents, le bus PCI, large et rapide, n'est pas nécessaire. Donc, une petite interface LPC a été créé pour être utilisée avec les périphériques lents comme les ports série, les ports parallèle et les lecteurs de disquettes. Il a une largeur de quatre bits à comparer aux 32, voire 64, bits du port PCI. Ce chemin sur quatre bits est partagée et utilisée par les données, les adresses et le contrôle (il est multiplexé). Donc, il est clair que LPC signifie Low Pin Count (petit largeur de bus) et c'est pourquoi il prend peu de place sur les cartes mères (ce qui est tout spécialement important pour les portables). Comme LPC opère à environ quatre fois la vitesse de l'ancien bus ISA, la bande passante n'est pas pire qu'avec l'ISA.

Donc, un ordinateur utilisant LPC aura tous les périphériques rapides sur le bus PCI, etc. et tous les périphériques lents sur l'interface de bus LPC. Tous les périphériques LPC seront intégrés à la carte-mère ; il n'existe pas d'emplacements pour cartes LPC. Malheureusement, LPC n'a aucune disposition pour le Plug-and-Play à contrario de PCI et ISA. Donc, chaque type de carte-mère l'utilisera différemment. Les spécifications suggèrent que cela soit fait abec l'ACPI mais les périphériques de ce bus utilisent quelque fois isapnp. Donc, si Linux ne peut pas configurer les ressources que LPC propose, vous devez espérer que le BIOS en sera capable (après avoir indique au BIOS que vous ne disposez pas d'un système d'exploitation PnP). Le support de Linux pour LPC, fin 2004, était très incomplet.

Un composant majeur du bus LPC est le composant superio, contenant des périphériques propriétaires : ports série et parallèle, lecteur de disquette, contrôleur de clavier, etc. Le BIOS pourrait même être sur le bus LPC.

En contraste avec les cartes PnP, les cartes non PnP ont toujours leurs ressources configurées au niveau matériel. C'est-à-dire qu'elles ont toujours une adresse et une IRQ sauf s'il existe une configuration par cavalier, etc. pour désactiver le périphérique. Quelque fois, le pilote du périphérique, ou un autre logiciel, peut trouver les ressources utilisées simplement en cherchant sur chaque adresse. Par exemple, scanport (Debian uniquement ?) cherche sur la plupart des adresses d'entrées/sorties et peut trouver des périphériques ISA. Mais, attention, cela peut bloquer votre PC. Quelque fois, il échouera dans sa recherche du matériel disponible (car le matériel a 0xff dans ses registres). Même s'il trouve le matériel, il n'affichera pas l'IRQ ou n'identifiera pas positivement le matériel.

Donc, une façon de trouver ce matériel est de lancer un pilote, qui pourrait chercher un tel matériel. En regardant dans les messages du démarrage, vous pourriez voir un pilote se lancer et découvrir le matériel. Sinon, vous pourriez avoir besoin de trouver un pilote et de le lancer (par exemple, en le chargeant comme un module).

Trouver le bon pilote peut être difficile. Quelque fois, il n'existe tout simplement pas de pilote car certains périphériques ne sont pas (encore) gérés par Linux. Pour déterminer le pilote dont vous avez besoin, jetez un œil sur toute documentation pouvant vous permettre d'identifier la carte. Si ceci échoue, jetez un œil à la carte elle-même, avec les noms/numéros importants inscrits sur les composants. Mais l'identification du module de pilote dont vous avez besoin pourrait n'être pas disponible sur la carte. Vous pouvez trouver l'identifiant FCC sur la carte, puis chercher sur Internet avec ce numéro pour essayer de trouver plus d'informations sur la carte (ou sur les composants en faisant partie).

Si la carte dispose de cavaliers pour configurer les ressources, alors vous pouvez regarder la façon dont ils sont installés. Il existe des cartes qui ont à la fois le support de PnP et des cavaliers. Elles fonctionnent comme des cartes à cavalier si PnP a été désactivé d'une façon ou d'une autre. Vous pourriez avoir besoin de la documentation (soit imprimée soit sur disquette) venant avec la carte. Peut-être pouvez-vous la trouver sur Internet.

Un des cas les plus difficiles est quand du logiciel fonctionnant sous MS Windows a été utilisé pour configurer une carte non PnP ou une carte PnP où la partie PnP a été désactivée. Donc, vous ne pouvez la configurer par PnP ou par des cavaliers. Dans ce cas, votre seul espoir est de chercher les adresses comme décrit dans la section intitulée « Cartes non PnP ». Ou essayez de trouver le logiciel MS qui l'a configuré.

Quelques personnes ont essayé d'utiliser Windows pour voir comment les ressources bus étaient configurées. Malheureusement, comme le matériel PnP oublie sa configuration de ressources bus à l'arrêt, la configuration peut ne pas être identique lors du redémarrage sous Linux pour le matériel non PnP (ou lorsque quelqu'un a désactivé PnP dans le périphérique soit par des cavaliers soit en utilisant des logiciels Windows). Même pour PnP, cela peut être le cas parce que dans beaucoup de cas, Windows et Linux acceptent simplement ce que le BIOS a fait. Mais là où Windows et/ou Linux font une configuration, ils peuvent le faire différemment. Donc ne comptez pas à ce que les périphériques soient configurés de la même manière.

L'USB (Universal Serial Bus, c'est-à-dire Bus Universel Série) est un bus à grande vitesse sur un câble externe qui se connecte au PC. Le bus externe a ses propres protocoles de communication et n'utilise pas les IRQ, adresses d'entrées/sorties (ou tout autre ressource bus) sur les câbles bus externes. La communication se fait par paquets comme sur Internet, seulement sur des allocations de tranches de temps, ce qui empêche un périphérique de manger le bus si d'autres périphériques en ont besoin. Il existe des tranches de temps libre qui permettent à tout périphérique d'envoyer un message court au contrôleur de bus sans avoir besoin des IRQ sur le bus.

Néanmoins, le contrôleur de bus USB intégré au PC a une IRQ et une adresse sur le bus PCI (ou ISA), utilisées pour la communication entre le CPU et tous les périphériques USB. Donc, il n'y a pas d'allocations de ressources nécessaires pour les périphériques individuels sur le bus USB. Vous pouvez aussi imaginer que tous les périphériques sur le bus USB partagent la même interruption et la même adresse. Si un périphérique est sur l'USB, il a besoin d'un pilote qui comprenne l'USB.

Mais, chaque périphérique USB a un identifiant, comme les cartes du bus PCI. Linux maintient donc une table des identifiants de façon à ce que les pilotes de périphérique puissent les vérifier et trouver ainsi leur périphérique. L'USB supporte aussi le « hot plug ».

« Hot plug » correspond à la connexion d'un périphérique sur un PC (habituellement avec un câble) et à sa détection immédiate. Si nécessaire, il est configuré avec les ressources bus. Son pilote est aussi lancé, peut-être en chargeant le module correspondant. Pour que ceci fonctionne, le matériel utilisé doit être conçu de façon approprié. Vous pouvez utiliser cette fonctionnalité avec certaines cartes PCI (Cardbus), périphériques USB et IEEE 1394 (Firewire).

Lorsqu'un nouveau périphérique est détecté, ses registres sont lus de façon à récupérer un numéro d'identifiant du périphérique. Pour trouver un pilote, Linux doit maintenir une table réalisant la correspondance entre numéro de périphérique et pilote. Cela n'est qu'à partir de la version 2.4 qu'une telle table a existé dans le noyau. Elle est nommée MODULE_DEVICE_TABLE.

« Hot Swap » vous permet de remplacer un ancien périphérique en l'enlevant et en branchant le nouveau. Vous avez donc interverti (swapped) les périphériques. Maintenant, en plus d'être capable de détecter le branchement d'un nouveau périphérique, la suppression d'un ancien périphérique doit aussi être détectée.

Les périphériques externes connectés par le port série via un câble (comme les modems externes) sont aussi appelé Plug-and-Play. Comme seul le port série a besoin de ressources bus (une IRQ et une adresse d'entrées/sorties), il n'y a pas de ressources bus à allouer pour ces périphériques. Dans ce cas, PnP est utilisé uniquement pour l'identification du modem (lire le numéro/code du modèle). Ceci est important dans le cas où ce modem est un modem logiciel (linmodem) et requiert un pilote spécifique. Il existe une spécification PnP pour de tels périphériques séries externes (quelque chose connecté au port série).

Linux ne supporte pas encore ceci ? Pour un modem matériel, le pilote série ordinaire suffira, donc il n'y a pas besoin de chercher un pilote avec serialpnp. Vous devez toujours indiquer au programme de communication sur quel port se trouve le modem. Avec PnP, vous n'auriez même pas besoin de faire ça. Avec l'arrivée des modems logiciels disposant de pilotes Linux (linmodem), il serait bien que les pilotes appropriés s'installent automatiquement via PnP.

Ceci signifie qu'une interruption est survenue alors qu'aucun pilote ne l'attendait. Il est improbable que le matériel ait généré une interruption par erreur. Il est plus probable que le logiciel comporte un petit bogue et n'a pas réalisé qu'un logiciel a fait quelque chose qui a généré cette interruption. Dans la plupart des cas, vous pouvez ignorer ce message en toute sécurité, et tout particulièrement si cela n'est arrivé qu'une ou deux fois lors du démarrage. Pour les messages du démarrage, regardez les messages qui lui sont proches pour trouver une indication sur ce qui s'est passé. Par exemple, si une recherche était en cours, il est possible que cela ait activé un périphérique physique qui en retour a généré une interruption, interruption que le pilote n'attendait pas. Le pilote n'écoutait peut-être pas le bon numéro d'IRQ.

Le BIOS a été incapable de configurer les ressources bus. Il peut exister un conflit d'interruptions qui ne peut être évité. Dell vous suggère que vous enleviez certaines des cartes non essentielles pour voir si le problème disparaît. Dans un cas, le problème était dû à une carte mère défectueuse.

Si vous utilisez isa-pnp, l'adresse d'entrées/sorties 0xa79 ne doit jamais être utilisé par un périphérique, quel qu'il soit. Donc, si un autre matériel utilise 0xa79 lorsque vous essayez de charger le module isa-pnp, vous obtiendrez ce message dans vos journaux de trace et isa-pnp quittera. Une façon de corriger cela est de charger le module isa-pnp bien plus tôt avant que tout autre matériel ne soit initialisé. Pour le PCMCIA, ceci impose de charger isa-pnp avant de lancer les modules cb et le service associé.

C'est en quelque sorte un réseau Plug-and-Play développé par Microsoft mais utilisable sous Linux. Vous connectez quelque chose sur un réseau et ce quelque chose n'a pas besoin d'être configuré mais ne va communiquer qu'avec des périphériques UPnP du réseau. Ici, « configurer » est utilisé dans le sens large et ne signifie pas simplement configurer les ressources bus. Un des objectifs est de permettre au gens connaissant peu de choses sur les réseaux ou sur la configuration et l'installation d'un routeur, d'une passerelle, d'une imprimante réseau, et cætera de le faire. Une utilisation majeure de UPnP serait dans les réseaux sans-fil.

UPnP utilise :

Ce guide pratique ne couvre pas UPnP. UPnP pour Linux est supporté par Intel qui a développé un logiciel spécifique. Il existe d'autres programmes qui font à peu près la même chose que UPnP. Une comparaison de ceux-ci est disponible sur http://www.cs.umbc.edu/~dchakr1/papers/mcommerce.html. Un projet UPnP pour Linux se trouve sur Sourceforge : Kit UPnP pour Linux

Il existe trois types d'adresses : adresses en mémoire principale, adresses d'entrées/sorties (ports) et adresses de configuration. Sur le bus PCI, les adresses de configuration constituent une plage d'adresses séparée un peu comme les adresses d'entrées/sorties. Sauf dans le cas compliqué des adresses de configuration ISA, qu'une adresse sur le bus soit ou non une adresse en mémoire principale, une adresse d'entrées/sorties ou une adresse de configuration dépend seulement du voltage sur certains fils du bus. Pour plus de détails sur les adresses de configuration du bus ISA, voir la section intitulée « Adresses de configuration du bus ISA (Port de lecture etc.) ».

Ces adresses sont aussi connues comme les « ports d'auto-configuration ». Pour le bus ISA, il n'existe pas techniquement de plage d'adresses de configuration, mais le CPU utilise une façon spéciale d'accéder aux registres de configuration PnP sur les cartes PnP. Dans ce but, trois adresses d'entrées/sorties sont allouées et chacune adresse un seul octet (il n'y a pas à proprement parler d'espace ou de plage). Il ne s'agit pas de trois adresses pour chaque carte mais de trois adresses partagées par toutes les cartes ISA-PnP.

Ces trois adresses sont nommées port de lecture (read-port), port d'écriture (write-port) et port d'adresse (address-port). Chaque port a une taille d'un octet. Chaque carte PnP dispose d'un grand nombre de registres de configuration, donc même les trois adresses ne sont pas suffisantes pour les registres de configuration d'une seule carte. Pour résoudre ce problème, chaque carte se voit affecter un numéro de carte en utilisant une technique appelée « isolation ». Voir la section intitulée « Isolation ISA » pour des détails plus complexes.

Ensuite, pour configurer une certaine carte, son numéro de carte est envoyé via l'adresse du port d'écriture pour indiquer à cette carte qu'elle doit écouter sur son port d'adresse. Toutes les autres cartes notent que ce n'est pas leur numéro de carte et donc n'écoutent pas. Ensuite, l'adresse d'un registre de configuration est envoyé sur le port d'adresse (à toutes les cartes, mais une seule écoute). Enfin, le transfert de données prend place avec ce registre de configuration sur cette carte soit en faisant une lecture sur le port de lecture soit en faisant une écriture sur le port d'écriture.

Le port d'écriture est toujours A79 et le port d'adresse est toujours 279 (en hexadécimal). Le port de lecture n'est pas fixe mais dépend du logiciel de configuration (tout en restant dans la plage 203-3FF) qui avec un peu de chance n'entrera pas en conflit avec les autres cartes ISA. Si un conflit se déclare, il changera l'adresse. Toutes les cartes PnP sont « programmées » avec cette adresse. Donc, si vous utilisez isapnp pour enregistrer ou connaître la configuration, celui-ci doit d'abord déterminer l'adresse du port de lecture.

Il existe deux nouveaux développements au niveau des interruptions PCI, qui ne sont pas couverts ici. Ils sont particulièrement importants pour les machines multiprocesseurs. Un des deux est le contrôleur avancé d'interruptions programmables (Advanced Programmable Interrupt Controller, APIC). Voir le fichier « IO-APIC » dans le répertoire i386 de la documentation du noyau. Ne confondez pas APIC avec ACPI (Advanced Configuration and Power Interface, c'est-à-dire Configuration Avancée et Interface de l'alimentation) qui n'est pas couvert par ce guide pratique. Le deuxième développement est le MSI (Message Signalled Interrupts, c'est-à-dire Interruptions Signalées par Message) où l'interruption est un message envoyé à une adresse particulière sur le bus principal de l'ordinateur (pas de lignes d'interruption nécessaires). Mais le périphérique qui envoie un tel message doit d'abord avoir le contrôle du bus principal de façon à ce qu'il puisse envoyer le message d'interruption. Un tel message contient plus que « J'envoie une interruption ».

Les interruptions PCI ordinaires sont différentes des interruptions ISA, mais comme elles sont d'habitude intégrées aux IRQ, elles se comportent à peu près de la même façon. Une différence majeure est que le BIOS fait cette intégration. Sous Linux, il n'est pas possible de le changer ?? sauf si le menu CMOS vous laisse le faire. Mais si vous avez l'APIC avancée, alors il existe un moyen de le spécifier.

Une autre différence majeure est que les interruptions PCI pourraient être partagées avec deux exceptions : 1. très ancien matériel PCI (avant 1995 ??) 2. matériel PCI défectueux qui aurait pu avoir une défection à l'usine (c'était fait de cette façon). Normalement, par exemple, l'IRQ 5 pourrait être partagée entre deux périphériques PCI. Cette capacité de partage est intégrée au niveau matériel et tous les pilotes de périphériques sont supposés le supporter. Notez que vous ne pouvez pas partager la même interruption entre les bus PCI et ISA. Néanmoins, les partages illégaux fonctionneront si au moins un des périphériques en conflit est utilisé tout le temps. « Utilisé » signifie ici qu'un programme a « ouvert » le périphérique (et ne l'a pas « fermé ») avec son code C, même si un tel programme peut être temporairement en sommeil, etc.

Voici quelques détails sur le système d'interruption du PCI. Chaque carte PCI (et chaque périphérique monté sur la carte mère) a quatres interruptions possibles : INTA#, INTB#, INTC#, INTD#. À partir de maintenant, nous les appellerons simplement A, B, C et D. Chacune a son propre câble de connexion sur un emplacement de carte PCI. Donc, pour un système à sept emplacements (pour sept cartes), il doit y avoir 7 x 4 = 28 lignes d'interruptions différentes pour les cartes. Mais, les spécifications permettent un plus petit nombre de lignes d'interruptions, donc les bus PCI semblent n'être fait que pour quatre lignes d'interruption. Ceci n'est pas trop restrictif car les interruptions peuvent être partagées. Appelons ces lignes (fils) W, X, Y, Z. Il existe un composant de routage des interruptions qui distribue les IRQ sélectionnées à W, X, Y, Z. Ce routage peut être modifié par le BIOS ou par un logiciel. Par exemple, W pourrait être routé vers l'IRQ5. Supposons que nous désignons l'interruption B du troisième emplacement comme l'interruption 3B. Alors, l'interruption 3B pourrait être connectée de façon permanente à W qui est routé sur l'IRQ 5.

Une simple méthode de connexions (fils) de ces lignes à partir de périphériques PCI (tel que le 3B) aux interruptions W, etc. serait de connecter toutes les interruptions A (INTA#) à la ligne W, toutes les B à X, etc. Cette méthode était utilisée plusieurs années auparavant mais ce n'est pas une bonne solution. Voici pourquoi. Si une carte a seulement besoin d'une interruption, elle doit utiliser à la fois A et B, etc. Du coup, INTA# est utilisé bien plus souvent que INTD#. Donc, il peut y avoir un nombre excessif d'interruptions partageant la première ligne (W connecté sur tous les INTA#). Pour contourner ce problème, il est possible de les connecter d'une façon aléatoire de façon à ce que chacune des quatres lignes d'interruption (W, X, Y, Z) partagera le même nombre d'interruptions PCI.

Une façon de le faire serait d'avoir câbler W en partage des interruptions 1A, 2B, 3C, 4D, 5A, 6B, 7C. Ceci se fait en connectant physiquement le câble W sur les câbles 1A, 2B, etc. De même, le câble X pourrait être connecté aux câbles 1B, 2C, 3D, 4A, 5B, 6C, 7D, etc. Donc, au démarrage, le BIOS établit un lien entre X, W, Y, Z et les IRQ. Après, il écrit l'IRQ que chaque périphérique utilise dans un registre de configuration du périphérique. À partir de maintenant, tout programme interrogeant ce registre peut trouver l'IRQ que le périphérique utilise. Notez que simplement écrire l'IRQ dans un registre d'une carte PCI ne configure pas l'IRQ pour ce périphérique.

Une utilisation pratique de ceci est que, en dernier ressort, il est poss ible de modifier les IRQ d'une carte PCI en l'insérant dans un emplacement différent. Dans l'exemple ci-dessus, INTA# d'une carte PCI sera connecté au câble W si la carte est insérée dans l'emplacement 1 (1A correspond à W) mais INTA# sera connecté au câble X s'il est inséré dans l'emplacement 4 (4A correspond à X).

Une carte dans un slot peut avoir jusqu'à huit périphériques, mais il n'y a que quatre interruptions PCI pour cela (A, B, C, D). Tout va bien car les interruptions peuvent être partagées de façon à ce que chacun des huit périphériques (s'ils existent) peut avoir une interruption. La lettre d'interruption PCI d'un périphérique est souvent fixe au niveau du périphérique. L'assignation des interruptions est faite lorsque le BIOS fait le mappage des interruptions PCI avec les interruptions ISA comme mentionné ci-dessus. S'il existe seulement quatre lignes (W, X, Y et Z) comme dans le précédent exemple, les choix de correspondance qu'a le BIOS PCI sont limités. Quelques cartes mères peuvent utiliser plus de lignes et ont donc plus de choix. Le BIOS sait comment tout ceci est connecté.

Sur le bus PCI, le BIOS affecte les IRQ (interruptions) de façon à éviter les conflits avec les IRQ qu'il connaît sur le bus ISA. Quelque fois, le menu CMOS du BIOS peut permettre d'affecter les IRQ aux cartes PCI ou d'indiquer au BIOS qu'elles sont les IRQ réservées pour les périphériques ISA. Aussi, un système d'exploitation PnP (par exemple MS Windows) pourrait essayer d'affecter les IRQ juste après avoir compris ce que le BIOS a fait. Les assignations sont connues comme la « table de routage ». Si MS Windows réalise une assignation dynamique des IRQ, c'est appelé « IRQ steering ». Le BIOS peut supporter ses propres « IRQ steering », que Linux pourrait utiliser. Donc, si Windows 9x change ce que le BIOS a fait et que vous utilisiez Linux après avoir utilisé Windows et après avoir éteint votre PC ? les IRQ pourraient être différentes. Windows 2000 et XP ne changent pas ce que le BIOS a fait, mais ils pourraient ajouter un nouveau périphérique (avec une nouvelle IRQ).

Vous pouvez penser que comme le PCI utilise les IRQ (créées pour le bus ISA), il pourrait être lent (car le bus ISA était lent). Pas vraiment. Le composant contrôleur d'interruption ISA a un fil d'interruption directement relié au CPU de façon à ce qu'il ait immédiatement l'attention. Alors que les signaux sur les anciens bus adresse et données ISA sont lents pour parvenir au CPU, les signaux d'interruption IRQ y arriveront très rapidement.

C'est uniquement pour l'ancien bus ISA. L'isolation est une méthode complexe d'affectation d'un point temporaire (numéro d'identifiant ou CSN, Card Select Number) à chaque périphérique PnP du bus ISA. Comme il existe des moyens plus efficaces (mais plus complexes) de le faire, certains pourraient dire qu'il s'agit d'une méthode simple. Seule une adresse d'écriture est utilisée pour les écritures PnP vers tous les périphériques pour que toutes les écritures vers cette adresse aillent sur tous les périphériques PnP. Cette adresse d'écriture est utilisé pour envoyer (affecter) un numéro de carte unique à chaque périphérique PnP. Pour être assigné, ce numéro de carte nécessite qu'un seul périphérique soit en écoute lorsque le numéro de carte est envoyé (écrit) à cette adresse commune. Tous les périphériques PnP ont un numéro de série unique qu'ils utilisent lors du processus d'isolation. Faire l'isolation est comme un jeu. Cela se fait en utilisant l'équivalent d'un bus commun de fils connectant tous les périphériques PnP au programme d'isolation.

Pour le premier tour du « jeu », tous les périphériques PnP écoutent sur ce fil et envoient simultanément une séquence de bits sur le fil. Les bits autorisés sont soit un 1 (voltage positif) soit un « 0 ouvert » sans voltage (circuit ouvert ou trois-états). Pour cela, chaque périphérique PnP commence à envoyer séquentiellement son numéro de série sur ce fil, voltage (circuit ouvert ou trois-états). Pour faire cela, chaque périphérique PnP lance simplement son numéro de série sur les fils, bit à bit, en commençant par le plus haut. Si un périphérique envoie un 1, un 1 sera entendu par tous les autres périphériques. Si tous les périphériques envoient un « 0 ouvert », rien ne sera entendu sur le fil. Le but est d'éliminer (à la fin du premier tour) tous les périphériques sauf celui possédant le numéro de série le plus important. « Éliminer » signifie enlever de ce tour du jeu et donc cesser temporairement d'écouter tout ce qui passe sur le fil. (Notez que tous les numéros de série ont la même taille.) Quand il ne reste qu'un seul périphérique en écoute, un numéro de carte lui est donné.

Tout d'abord, considérez seulement le bit le plus haut du numéro de série qui est placé sur le fil par tous les périphériques qui n'ont pas encore de numéro de carte. Si un périphérique PnP envoie un 0 (0 ouvert) mais entend un 1, cela signifie qu'un ou plusieurs autres périphériques PnP a un numéro de série plus important, donc il se supprime temporairement pour ce tour. Maintenant, les périphériques restant en jeu (pour ce tour) ont tous le même bit de haut niveau (un 1), donc nous pouvons supprimer ce bit et continuer avec le « reste du numéro de série » pour la suite du tour. Ensuite, recommencez depuis le début de ce paragraphe et répétez jusqu'à ce que le numéro de série soit examiné en entier pour chaque périphérique (voir plus bas pour les cas « tous à 0 »).

Donc, il est clair que seuls les cartes avec un petit numéro de série sont éliminées lors d'un tour. Mais qu'arrive-t'il si tous les périphériques du jeu envoient un 0 comme leur bit de haut niveau ? Dans ce cas, un « 0 ouvert » est envoyé sur la ligne et tous les participants restent en lice. S'ils ont tous un 0 au début, alors les 0 sont supprimés comme les 1 du paragraphe ci-dessus. Le jeu continue alors avec le bit suivant du numéro de série).

A la fin du tour (après que le dernier bit ait été envoyé), seul un périphérique PnP, celui possédant le plus haut numéro de série, reste en jeu. Il se voit attribué un numéro de carte et quitte le jeu définitivement. Ensuite, tous les autres périphériques du tour précédent (qui n'ont donc pas de numéro de carte) reviennent dans le jeu et un nouveau tour commence, avec un participant en moins. Éventuellement, tous les périphériques PnP se voient assignés un numéro de carte. Il est facile de prouver que cet algorithme fonctionne. L'algorithme actuel est un peu plus complexe que celui présenté ci-dessus car chaque étape est répétée deux fois pour s'assurer, et ces répétitions sont faites d'une façon un peu différente (mais utilisant la même idée de base).

Une fois tous les numéros de carte assignés, ils sont utilisés pour s'adresser à chaque périphérique PnP pour envoyer/lire des données de configuration. Notez que ces numéros de carte sont seulement utilisés pour la configuration PnP et ne sont pas utilisés pour les communications normales avec le périphérique PnP. Lorsque l'ordinateur démarre, un BIOS PnP fera l'isolation puis s'occupera de la configuration PnP. Après ça, tous les numéros de carte sont « perdus » d'une telle façon que si quelqu'un veut changer (ou inspecter) la configuration une nouvelle fois, l'isolation devra être refaite intégralement.

Si un bus dispose d'une fonctionnalité de maîtrise du bus, il est peu probable que des ressources seront nécessaires pour le DMA sur ce bus. Par exemple, le bus PCI n'a pas besoin des ressources DMA car il dispose de cette fonctionnalité. Néanmoins, la « maîtrise du bus » est souvent appelé DMA. Mais, comme il ne s'agit pas strictement de DMA, il ne nécessite aucune ressource DMA. Les bus locaux ISA et VESA n'ont pas de maîtrise du bus. Les anciens bus MCU et EISA l'avaient.