Guide pratique du 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, et cætera. Mais tout d'abord, si la date du document est vieille de plus de plusieurs 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 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 tous les ans et seront disponibles à la navigation et 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.15, d'août 2007.

Pour un historique complet des révisions, voir le fichier source (dans son format DocBook SGML) sur http://cvsview.tldp.org/index.cgi/LDP/howto/linuxdoc/Plug-and-Play-HOWTO.sgml..

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, et cætera. Il trouve tous les périphériques du bus PCI et tous les périphériques supportant PnP sur l'ancien bus ISA. Avant PnP, beaucoup de périphériques étaient automatiquement recherchés en utilisant des méthodes non PnP mais n'étaient pas trouvés quelque fois. 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és avec PnP) peuvent souvent être détectés par des méthodes n'utilisant pas PnP. Le bus PCI 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. À la fin du 20è siècle, on pouvait dire que Linux n'était pas un système d'exploitation PnP. Mais il est dit 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 correctement.

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és par Linux ou parce qu'ils ont été mal configurés), 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.

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 possibles 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. Concernant 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-vous que, parfois les problèmes semblant être relatifs à PnP sont dûs en réalité à un matériel défectueux ou à un matériel non conforme aux spécifications PnP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 la communication de 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 et, si nécessaire, le pilote donnant une commande pour changer (réinitialiser) les ressources bus. Souvent, « PnP » ne signifie 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 leur pilote 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. Quelquefois, les ressources bus pouvaient être configurées sur le matériel par un pilote (généralement écrit seulement pour un système MS mais dans de rares cas supporté aussi par un pilote Linux). Cela ressemblait à du PnP mais aucun protocole standardisé n'était utilisé donc il ne s'agissait pas vraiment de PnP. Certaines cartes contiennent un paramètrage par cavaliers qui peut être surchargé par un tel pilote. Pour Linux avant le PnP, 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. Mais ces méthodes sont toujours utilisées de nos jours pour permettre à Linux d'utiliser du matériel non PnP. Et, quelque fois, ces vieilles méthodes sont toujours utilisées de nos jours sur du matériel PnP (après que le BIOS ait affecté des ressources aux matériels par les méthodes PnP).

Le bus PCI ressemblait au PnP dès le début mais il n'a pas été appelé PnP ou « plug and play », ce qui a eu comme résultat que PnP signifie souvent PnP sur le bus ISA. Dans la documentation, PnP signifie habituellement PnP sur le bus ISA comme sur le bus PCI.

Voici comment PnP devrait fonctionner. L'hypothétique 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, et cætera). Bien sûr, s'il a réservé des ressources bus utilisées pour des périphériques non PnP (s'il les connaît), il ne les donne pas. 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, et cætera. 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 communiquée.

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'adresses. 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, et cætera. 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, le noyau 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ées 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. Les BIOS le font ainsi que MS Windows mais le Linux standard ne le fait pas. Mais, d'une certaine façon, il le fait car il utilise souvent ce que le BIOS a fait. 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 dont 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 de son ancienne configuration, alors il n'y aura pas de matériel à configurer au prochain démarrage, mais il semble oublier sa 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 de la carte mère). 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 leur pilote). peuvent toujours trouver les informations nécessaires en utilisant les fonctions disponibles dans le noyau Linux.

Pour voir ce qui se trouve sur le bus PCI, exécutez lspci ou lspci -vv. Ou vous pouvez aussi saisir scanpci -v pour la même information dans le format de code numérique où le périphérique est indiqué par numéro (par exemple : « device 0x122d ») au lieu du nom, et cætera. Dans de rares cas, scanpci trouvera un périphérique que lspci n'arrive pas à trouver.

Les messages au démarrage sur votre écran affichent les périphériques qui ont été trouvés sur les différents bus (utilisez shift-PageUp pour les voir). Voir Messages au démarrage.

ISA est l'ancien bus des PC compatibles IBM alors que PCI est le nouveau bus, plus rapide, d'Intel. Le bus PCI a été conçu pour ce qui est appelé de nos jours PnP. Ceci rend facile (comparé à ce qu'il faut faire pour le bus ISA) la découverte de l'affectation des ressources bus PnP aux périphériques matériels.

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 qui peut être PnP si le noyau est compilé avec certaines options. Le BIOS peut affecter des IRQ mais Linux peut aussi affecter certains d'entre eux ou même les refaire ce que le BIOS a déjà fait. La partie de configuration de ACPI (Advance Configuration and Power Interface) est conçu pour faciliter la propre configuration des systèmes d'exploitation. Linux peut utiliser l'ACPI si le noyau a été compilé avec son support.

Dans Linux, il est traditionnel qu'un pilote de périphérique fasse sa propre configuration de bas niveau. C'était difficile jusqu'au moment où le noyau Linux a fourni le logiciel que les pilotes peuvent utiliser pour se faciliter le travail. Aujourd'hui (2005), c'est arrivé à un point où le pilote peut simplement appelé la fonction pci_enable_device() du noyau et où le périphérique se voit configuré en étant activé et en récupérant une IRQ (si nécessaire) et les adresses affectées au périphérique. Cette affectation pourrait être ce qui avait été affecté auparavant par le BIOS ou ce que le noyau avait réservé quand le périphérique PCI ou ISAPNP a été détecté par le noyau. Il existe même une option ACPI pour que le noyau affecte toutes les IRQ des périphériques lors du démarrage.

Donc aujourd'hui, d'une certaine façon, les pilotes font toujours la configuration mais ils peuvent la faire en demandant simplement au noyau de s'en charger (et Linux pourrait ne pas avoir besoin de faire grand chose car il est quelque fois capable d'utiliser ce qui a déjà été configuré par le BIOS ou par lui-même). Donc, c'est vraiment la partie du noyau, hors du pilote, qui fait la grande partie de configuration. Du coup, il pourrait être correct d'appeler Linux un système d'exploitation PnP, au moins pour les architectures communes.

Ensuite, lorsqu'un pilote découvre son périphérique, il demande à connaître les adresses et IRQ affectés (par le BIOS ou par Linux) et, habituellement, les accepte simplement. Mais, si le pilote le souhaite, il peut essayer de modifier les adresses en utilisant les fonctions fournies par le noyau. Cependant, le noyau n'acceptera pas d'adresses entrant en conflit avec d'autres périphériques ou des adresses que le matériel ne peut pas supporter. Quand le PC démarre, vous pouvez noter les messages à l'écran montrant que certains pilotes de périphériques Linux ont trouvé leurs périphériques matériels et quels sont leurs IRQ et adresses.

Donc, le noyau fournit des fonctions (programmes) que les pilotes peuvent utiliser pour trouver si leur périphérique est présent, la façon dont il est configuré et les fonctions qui permettent de modifier la configuration si nécessaire. Le noyau 2.2 pouvait faire ceci pour le bus PCI seulement mais le noyau 2.4 contient cette fonctionnalité pour les bus ISA et PCI (à condition que les options PnP et PCI appropriés ont été sélectionnées avant la compilation du noyau). Le noyau 2.6 est arrivé avec une meilleure utilisation de l'ACPI. Ceci ne garantie en rien que tous les pilotes utilisent complètement et correctement ces fonctionnalités. Les périphériques propriétaires que le BIOS ne connait pas pourraient ne pas être configurés tant qu'une configuration manuelle ne soit effectuée.

De plus, le noyau tente d'éviter les conflits d'adresses en ne permettant pas à deux périphériques d'utiliser les même ressources bus en même temps. Au début, ce n'était valable que pour les IRQ et les DMA mais, maintenant, cela s'adresse aussi aux adresses.

Si vous avez un ancien bus ISA, le programme isapnp doit être exécuté au démarrage pour trouver et configurer les périphériques PnP sur le bus ISA. Regardez les messages avec « dmesg ».

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 écrits. 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 si vous connaissez la programmation en C, ces fichiers sont écrits d'une telle façon qu'il ne vont pas vous permettre d'é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. Voir aussi le livre d'O'Reilly : Linux Device Drivers, 3è édition, 2005. Le texte complet est disponible sur Internet.

Il existe un certain nombre d'autres points 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 alternative serait d'essayer de réallouer les ressources déjà affectées quand un pilote n'obtient pas toutes les ressources qu'il a demandées.

Le problème de la « rareté des ressources bus » devient de moins en moins réel 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 rende 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'adresses est disponible pour les entrées/sorties des périphériques. Alors que l'espace d'adresses 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'adresses 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).

Il y a eu au moins une tentative pour faire de Linux un vrai système d'exploitation PnP. Voir http://www.astarte.free-online.co.uk. Bien que développé dès 1998, elle n'a jamais été intégrée au noyau (mais aurait certainement dûe l'être).

Quelle que soit votre réponse au BIOS, le BIOS PnP utilisera PnP pour paramétrer le disque dur, le lecteur de disquette, la carte vidéo et le clavier, afin de permettre au système de démarrer. 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 dites 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. Même si vous avez Windows 2000 ou XP sur le même PC, cela devrait fonctionner de toute façon tout simplement parce que Windows et Linux sont tous les deux à priori 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 à faire autrement.

Les BIOS modernes vous permettent d'allouer manuellement des ressources, 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 peut ê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 outil identique) sous Windows.

Pour le PCI, le BIOS devrait aussi vous permettre d'affecter les IRQ aux emplacements de cartes 1, 2, 3, 4, et cætera. Si vous le faites, vous devez connaître 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 les 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és et comment les périphériques non PnP ont été configurés 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, pratiquement toutes les nouvelles cartes internes sont Plug-and-Play. Du coup, 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. La façon dont 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 ?? ».

Les pilotes de périphériques (avec l'aide de fonctions du noyau) peuvent être écrits pour utiliser des méthodes PnP pour configurer les ressources bus du matériel mais seulement pour le périphérique qu'ils contrôlent. Mais beaucoup de pilotes de périphériques acceptent directement ce que le BIOS ou Linux a configuré et utilise le code fourni par le noyau pour découvrir comme ce périphérique a été configuré. Comme le pilote a vérifié la configuration et la certainement reconfiguré, il connaît de façon évidente la configuration et il n'y a aucun besoin de lui donner cette information. C'est dont la façon la plus simple de le faire car vous n'avez rien à faire si le pilote fait tout.

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 configurant le BIOS au démarrage (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.

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 ».