The Linux Plug-and-Play HOWTO David S.Lawyer v0.00, novembre 1998 Un aiuto per districarsi e gestire i dispositivi Plug-and-Play. Come far sì che il proprio sistema Linux supporti il Plug-and-Play. Questa prima versione è incompleta ma dovrebbe essere un po' d'aiuto. Traduzione di Giovanni Bortolozzo (borto at pluto.linux.it). 1. Introduzione 1.1. Copyright, Marchi registrati, Disclaimer e Ringraziamenti 1.1.1. Copyright Copyright (c) 1998 by David S. Lawyer. Please freely copy and distribute (sell or give away) this document. You may create derivative works and distribute them provided you: I. For the case of minor changes and corrections where there exists a current maintainer: Send your proposed changes to the current maintainer first. You may distribute (per II. below) only if the current maintainer neglects to incorporate your changes in a timely manner. If the changes are only to correct typos, you need not wait for a reply from the maintainer before you distribute. II. In all other cases: 1. Make a good faith effort to insure that a copy of the derivative work (including any master copy) gets on the Internet at a well- known (and mirrored) site for free downloading. 2. If you change the license, license the work in the spirit of this license, or use GPL (Free Software Foundation). 3. The major authors become the copyright owners (not to exceed 2). Minor contributions do not make you an author. 4. Make a good faith effort to contact the maintainer (or copyright owners if there is no maintainer) to let them know what you have done. If the changes are extensive, then you should also attempt to make more such contacts (including prior to your project). 5. Give full credit to significant previous authors and contributors although the credits section need not exceed 1% of the length of the document. 1.1.2. Marchi registrati Se alcune parole sono marchi registrati, il contesto dovrebbe mettere in chiaro a chi appartengono. Per esempio "MS Windows" (o semplicemente "Windows") implica che "Windows" appartiene a Microsoft (Micro$oft). 1.1.3. Disclaimer Molte delle informazioni in questo HOWTO sono state ricavate dal Serial HOWTO, da Internet, commessi di negozi ecc. e possono non essere affidabili. Anche se non ho l'intenzione di mettervi fuori strada, probabilmente ci sono parecchi errori in questo documento. Vi invito a farmeli notare. Poiché questa è documentazione libera, dovrebbe essere ovvio che né io né gli autori precendenti possiamo essere ritenuti legamemente responsabili per qualsiasi errore. N.d.T.: ovviamente nemmeno il traduttore può essere ritenuto legalmente (e nemmeno moralmente) responsabile di eventuali errori. 1.2. Piani Futuri: Come Aiutare Invito a segnalarmi qualsiasi errore in fatti, opinioni, logica, battitura, grammatica, chiarezza, link, ecc. Ma per prima cosa, se la data del documento è più vecchia di un mese, si controlli se si è in possesso dell'ultima versione. Invito inoltre ad inviarmi qualsiasi informazioni che si pensa sia pertinente a questo documento. Per questa prima versione, 0.00, non ho nemmeno guardato il libro "PnP System Architecture" e non ho pienamente compreso il PnP. Inoltre, non ho ancora confrontato le due patch in competizione per rendere Linux un sistema operativo PnP. Non ho neppure ben spiegato come il BIOS configuri il PnP (mettendo un attimo da parte come il SO Linux lo fa). Quindi questo HOWTO è incompleto e potrebbe essere inaccurato (mi si faccia sapere cosa c'è di errato). In questo HOWTO ho usato ?? per indicare che in realtà non so la risposta. Qualcuno ha voglia di migliorare (riscrivere) e mantenere questo HOWTO? Sto cercando qualcuno che prenda il mio posto. 1.3. Nuove Versioni di questo HOWTO Le nuove versione del Plug-and-Play-HOWTO saranno disponibili (anche per il download) nei siti che fanno da mirror a LDP. Per una lista di tali siti si veda: . Quando si è in uno dei mirror, si scelga "Linux Documentation Project" (LDP) e poi si cerchi la seconda occorrenza di questo HOWTO. Sono disponibili diversi formati. Se si vuole semplicemente controllare la data dell'ultima versione potrebbe essere meglio non usare un mirror, quindi si dia un occhio a: . N.d.T.: l'ultima (e più recente) traduzione in italiano di questo documento è reperibile nei mirror di ILDP ( ) e scaricabile in diversi formati dai relativi siti ftp. 2. Cosa Dovrebbe Fare il Pnp: Allocare "Risorse" 2.1. Che Cos'è il Plug-and-Play (PnP)? Il Plug-and-Play è un metodo per configurare automaticamente (a basso livello) schede e altri dispositivi presenti nel proprio computer e per dire poi agli appropriati gestori di dispositivo ("device driver") quello che si è fatto. Il compito del Plug-and-Play è di far "accoppiare" dispositivi fisici con il software (gestore di dispositivo) che funziona con essi e di stabilire dei canali di comunicazione tra ogni dispositivo e il suo gestore. Messa in altro modo, il PnP alloca le seguenti "risorse" per i driver e l'hardware: indirizzi I/O, IRQ, canali DMA e regioni di memoria. Se non si capisce cosa siano queste 4 cose si leggano le sotto sezioni che seguono. Una volta assegnate queste risorse, i file per i dispositivi nella directory /dev/ sono pronti per l'uso (a patto che il dispositivo esista fisicamente nel proprio PC). Quindi il PnP configura risorse, ma configura solo certe risorse. Anche utilizzando pienamente il PnP, buona parte della configurazione dei dispositivi è fatta da qualche altra cosa. Per la configurazione dei modem, è inviata una "stringa di inizializzazione" al modem attraverso l'indirizzo di I/O del "canale". Questa "stringa di inizializzazione" non ha niente a che vedere con il PnP, sebbene il "canale" usato per inviarla al modem è stato allocato dal PnP. L'impostazione della velocità (e di molti altri parametri) di una porta seriale è fatta inviando messaggi al gestore del dispositivo ("device driver") da programmi eseguiti dall'utente (spesso automaticamente all'avvio del sistema). Anche questa configurazione non ha niente a che spartire con il PnP. Quindi quando si parla di PnP, con "risorse" si intende solo un sottoinsieme limitato delle risorse e con "configurazione" si intende solo un certo tipo di configurazione. 2.2. Come Fa Un Computer Trovare i Dispositivi (e viceversa) Un computer consta di una CPU/processore per effettuare la computazione e di memoria per immagazzinare programmi e dati. Inoltre, ci sono diversi dispositivi come vari tipi di dischi, una scheda video, una tastiera, scheda di rete, schede modem, schede audio, porte seriali e parallele, ecc. C'è anche un alimentatore per fornire energia elettrica, diversi bus sulla scheda madre per connettere assieme i dispositivi e la CPU, e un case per metterci tutto dentro. In tempi antichi quasi tutti i dispositivi avevano la proprio scheda di interfaccia (scheda a cirtuito stampato). Oggi, oltre a tali schede, molti "dispositivi" hanno un piccolo chip montato permanentemente in un unica scheda detta "scheda madre". Le schede che vengono inserite nella scheda madre possono contenere più di un dispositivo. I chip di memoria sono qualche volta considerati come dispositivi ma non sono plug-and-play nel senso usato in questo HOWTO. Affinché un computer funzioni correttamente, ogni dispositivo dev'essere sotto il controllo del suo gestore o "device driver" (un software che è parte del sistema operativo e che viene eseguito nella CPU). Questi gestori di dispositivo sono associati con "file speciali" nella directory /dev, sebbene non siano propriamente dei file. Hanno nomi come hda1 (la prima partizione sul disco fisso a), ttyS0 (la prima porta seriale), eth1 (la seconda scheda ethernet), ecc. Per rendere le cose più complicate, il particolare device driver selezionato, diciamo per eth1, dipenderà dal tipo di scheda ethernet che si ha. Quindi eth1 non può semplicemente essere assegnato ad una qualsiasi scheda ethernet che si ha, ma ad un certo driver che funzionerà con il tipo di scheda ethernet installata. Per controllare un dispositivo, la CPU (sotto il controllo del device driver) invia comandi e legge informazioni dai vari dispositivi. Per poterlo fare ogni device driver deve conoscere l'indirizzo usato per tali comunicazioni. La conoscenza di tale indirizzo è equivalente all'impostazione di una canale di comunicazione, anche se quel "canale" è in realtà in bus dati dentro al PC che è condiviso praticamente tutte le altre cose. I PC hanno 3 spazi di indirizzi: memoria principale, I/O e configurazione (solo nel bus PCI). Solo i primi due (memoria e I/O) sono configurati dal PnP. Tutti questi 3 tipi di spazi di indirizzi condividono lo stesso bus all'interno del PC (inoltre, nel caso del bus PCI, il bus è usato pure per i dati). Ma il potenziale di alcune linee dedicate dice a tutti i dispositivi quando un indirizzo è nello spazio di I/O oppure nello spazio di memoria. I dispositivi sono normalmente localizzati nello spazio di indirizzi I/O (sebbene in alcuni casi questi allochino pure dello spazio in memoria principale). Un indirizzo I/O qualche volta è detto semplicemente "I/O", "IO", "i/o" o "io". È pure usato il termine "porta di I/O". Ci sono due passi principali per allocare gli indirizzi I/O, ecc.: (quel che "ecc." comprende sarà spiegato a breve) 1. Impostare l'indirizzo I/O, ecc. sulla scheda (in uno dei suoi registri) 2. Fare in modo che il gestore del dispositivo sappia qual è questo indirizzo I/O, ecc. Un terzo passo è dare al dispositivo e al suo gestore un nome nella directory /dev come hda, ttyS0 o eth1. Il processo in due passi appena visto è in qualche modo simile al problema di trovare il numero di casa di qualcuno in una strada. Si deve conoscere il numero di casa e qualcuno deve installare un numero nella facciata della casa in modo che possa essere trovata. Nei computer, il device driver deve conoscere l'indirizzo e il dispositivo hardware deve installare lo stesso indirizzo in uno dei suoi registri. Devono essere fatte entrambe queste cose, ma alcuni fanno l'errore di farne solo una e poi si sorprendono quando il computer non riesce a trovare il dispositivo. Ora per spiegare (nelle tre sezioni successive) cosa comprende l'"ecc." di prima: ``IRQ'', ``Canali DMA'', e ``Regioni di Memoria''. Tutte queste cose (compresi l'indizzi I/O) sono dette "risorse". 2.3. IRQ -- Panoramica Dopo aver letto questa sezione si può leggere ``Interrupt -- Dettagli'' per ulteriori dettagli. Quanto segue è intenzionalmente super semplificato. Oltre agli indirizzi, si deve gestire anche un numero di interruzione ("interrupt") (come IRQ5), detto numero di IRQ (Interrupt ReQuest = Richiesta di Interruzione). Si è già detto prima che il gestore del dispositivo deve conoscere l'indirizzo di una scheda per poter essere in grado di comunicare con quest'ultima. Ma cosa dire della comunicazione in senso opposto? Si supponga che il dispositivo necessiti di conoscere l'indirizzo (o il tipo) del suo gestore in modo da porterlo chiamare per chiedere aiuto. Per esempio, il dispositivo potrebbe aver appena ricevuto un sacco di byte destinati alla memoria principale e quindi gli serve chiamare il suo gestore per trasferire questi dati dal suo buffer praticamente pieno alla memoria principale. Il dispositivo chiede questo aiuto imponendo una tensione particolare in una linea di interrupt (parte del bus). Ci sono l'equivalente di 16 linee e ognuna di queste è comandata (indirettamente) da un certo gestore di dispositivo. Ogni linea ha un unico numero di IRQ (Interrupt ReQuest). Il dispositivo deve mettere il suo interrupt nella linea corretta e il gestore del dispositivo deve restare in attesa dell'interruzione sulla linea corretta. Su quale linea è messo è determinato dal numero di IRQ salvato nel dispositivo. Lo stesso numero di IRQ dev'essere noto al gestore del dispositivo in modo che questo sappia su quale linea di IRQ mettersi in ascolto. 2.4. Canali DMA DMA sta per "Direct Memory Access" (Accesso Diretto alla Memoria). È il posto dove un dispositivo ha la possibilità di prendere il controllo del bus principale del computer dalla CPU e trasferire i dati direttamente nella memoria principale. Normalmente la CPU vorrebbe fare questo trasferimento in due passi: 1. leggendo i dati dallo spazio di I/O del dispositivo e mettendoli dentro la CPU stessa 2. scrivendo questi dati dalla CPU alla memoria principale. Con il DMA si fa solitamente un solo passo inviando i dati direttamente dal dispositivo alla memoria. Il dispositivo deve avere tale funzionalità nel suo hardware e quindi non tutti i dispositivi possono fare un DMA. Mentre è in esecuzione il DMA la CPU non può fare molto in quanto il bus principale è usato per il trasferimento DMA. Quando un dispositivo vuole fare un DMA invia una richiesta DMA usando una linea dedicata per la richiesta di DMA in modo analogo ad una richiesta di interrupt. In realtà il DMA potrebbe essere gestito usando interrupt ma ciò introdurrebbe alcuno ritardi, cosicché è più veloce da fare utilizzando un tipo particolare di interrupt detto DMA- request. Come le interruzioni, le richieste DMA sono numerate in modo da identificare quale dispositivo sta facendo la richiesta. Questo numero è chiamato DMA-channel (canale DMA). Poiché tutti i trasferimenti DMA usano il bus principale (e solo uno può essere attivo in un determinato istante) in realtà usano tutti lo stesso canale, ma il numero del "canale DMA" serve per indentificare chi sta usando il "canale". Nella scheda madre esistono dei registri hardware che contengono lo stato attuale di ogni "canale". Quindi per poter effettuare una richiesta DMA, il dispositivo deve conoscere il suo numero di canale DMA che deve essere salvato in un registro nel dispositivo fisico. 2.5. Regioni di Memoria Ad alcuni dispositivi è assegnato dello spazio di indirizzi nella memoria principale come avviene per lo spazio di indirizzi I/O. Quando di installa una scheda di questo tipo, in effetti si sta inserendo un modulo in memoria (per la memoria principale, non solo per la memoria I/O). Questa memoria è condivisa dal dispositivo con la CPU (eseguendo il gestore del dispositivo). Questa memoria può servire come mezzo di "trasferimento" diretto di dati tra il dispositivo e la memoria principale. Non è veramente un trasferimento in quanto il dispositivo mette i dati nella propria memoria che "casualmente" è la memoria principale. Sia la scheda che il gestore del dispositivo devono sapere dov'è questa memoria. 2.6. "Risorse" in Due Posti Quindi i gestori dei dispositivi devono essere in qualche modo "collegati" all'hardware che controllano. Questo è fatto fornendo le "risorse" (I/O, Memoria, IRQ e DMA) sia al dispositivo fisico che al software di gestione. Per esempio, nel caso di una porta seriale ci sono solo 2 (delle 4 possibili) risorse: un IRQ e un indirizzo I/O. Entrambi questi valori deve essere forniti al gestore del dispositivo e al dispositivo fisico stesso. Al gestore (e al suo dispositivo) è dato un nome (come ttyS1). L'indirizzo e il numero di IRQ sono salvati in un registro delle scheda del dispositivo fisico (o in un chip nella scheda madre). 2.7. Il Problema L'architettura di un PC fornisce solo in numero limitato di IRQ, canali DMA, indirizzi I/O, ecc. Se ci fossero solo alcuni dispositivi e tutti questi avessero le risorse standardizzate (come indizzi I/O e numeri IRQ unici) non ci sarebbero problemi a collegare i gestori dei dispositivi ai dispositivi stessi. Ogni dispositivo avrebbe delle risorse fisse e non andrebbe in conflitto con qualsiasi altro dispositivo nel computer. Non ci sarebbero due dispositivi che vorrebbero avere gli stessi indirizzi di I/O, numeri di IRQ, ecc. Ogni driver potrebbe quindi essere programmato con gli indirizzi di I/O, l'IRQ, ecc. già codificati all'interno del programma. La vita sarebbe più semplice. Ma così non è. Non solo oggi ci sono così tanti dispositivi che i conflitti sono una cosa normale, ma qualchevolta uno ha necessità di averne anche più di uno dello stesso tipo. Per esempio qualcuno potrebbe avere più di un disco fisso, un po' di porte seriali, ecc. Per queste ragioni i dispositivi devono possedere un minimo di flessibilità in modo che possano essere impostati a un qualsivoglia indirizzi, IRQ, ecc. siano necessari per evitare i conflitti. Ma alcuni IRQ e indirizzi, come quello del clock e della tastiera, sono piuttosto standard. Questi non hanno bisogno di tale flessibilità. A parte il problema nel conflitto nell'allocazione delle risorse, c'è anche un problema nel caso si commetta un errore nel dire al device driver quali sono le risorse. Per esempio, si supponga di aver messo IRQ 4 in un file di configurazione quando in realtà il dispositivo è impostato all'IRQ 5. Questo è un altro tipo di errore nell'allocazione delle risorse. L'allocazione delle risorse, se fatta correttamente, stabilisce inoltre i canali di comunicazione tra l'hardware fisico e i relativi device driver. Per esempio, se un determinato intervallo di indirizzi I/O (risorsa) è allocato sia al gestore di dispositivo che ad un pezzo di hardware, allora in questo modo si è stabilito un canale di comunicazione unidirezionale tra loro. Il driver può inviare comandi ed informazioni al dispositico. In realtà è un po' più che unidirezionale, in quanto il driver può ottenere informazioni dal dispositivo leggendone i suoi registri. Ma il dispositivo in questo modo non può inizializzare una qualsiasi comunicazione. L'allocazione di un IRQ lo rende un canale di comunicazione a due vie, nel quale sia il driver che il dispositivo possono iniziare una comunicazione. 3. La Soluzione Plug-and-Play (PnP) 3.1. Introduzione Il Plug-and_Play (PnP) è un metodo per automatizzare l'assegnazione di risorse PnP all'harware e al corrispondente software. Ovvero per far corrispondere dispositivi con i loro gestori di dispositivo e specificare i relativi "canali" di comunicazione. Prima del Plug-an- Play le risorse erano impostate suoi dispositivi hardware tramite ponticelli (jumper), mentre erano assegnate al software di gestione tramite file di configurazione (o qualcosa di simile) oppure interrogando il dispositivo (cosa che non sempre funzionava bene). Ad un PnP completo (che a sua volta non sempre funziona correttamente) partecipano sia un BIOS PnP che un sistema operativo PnP. Quando il computer è acceso, il chip del BIOS esegue un suo programma per avviare la macchina. Se il sistema operativo è immagazzinato nel disco fisso (com'è ormai usuale) allora il BIOS deve essere conscio della presenza del disco fisso. Se il disco fisso è PnP allora il BIOS potrebbe usare uno dei metodi PnP per trovarlo. Inoltre, per configurare il BIOS quando il computer si avvia, sono richiesti uno schermo (scheda video) e una tastiera, e quindi il BIOS deve configurare questi dispositivi se necessario. Un volta che il BIOS ha identificato il disco fisso, la scheda video e la tastiera è pronto per fare il "boot" (caricare il sistema operativo dal disco fisso). Se si è detto al BIOS che si ha un sistema operativo PnP, allora dovrebbe fare solo questo e poi lasciare al sistema operativo la conclusione della configurazione PnP. Diversamente, un BIOS PnP probabilmente proverà a fare da solo il resto della configurazione PnP. 3.2. Linux Necessita del PnP Il PnP è stato inventato da Wintel (il binomio Microsoft e Intel). Un po' per questa ragione (forse dovuto parzialmente alla sindrome "non l'abbiamo inventato noi"), e in parte a causa del fatto che non piaceva il modo in cui era stato implementato, ci sono stati alcuni pregiudizi giustificati sul PnP nella comunità Linux. Ma che piaccia o meno, oggigiorno praticamente tutto l'hardware è PnP e Linux non ha scelta, se non quella di gestire il PnP. 3.3. Bus Il PnP è stato pensato per funzionare con qualsiasi bus come ISA e PCI. ISA è il vecchio bus dei PC IBM, mentre PCI è il bus più nuovo e veloce di Intel. Il bus ISA dovrebbe cominciare a scomparire. Il PCI riserva sul bus molti indirizzi di configurazione per la configurazione PnP. Linux usa alcuni di questi indirizzi per scoprire quali dispositivi PCI presenti sul bus sono PnP (che dire dei dispositivi non PnP sul bus PCI ??), e mette poi le informazioni relative a quest'ultimi nel "file" /proc/pci. Nel caso del bus ISA c'è un problema reale poiché, diversamente dal bus PCI che è stato progettato per il PnP, nessuno aveva in mente il PnP quando è stato progettato il bus ISA e praticamente non ci sono indirizzi I/O disponibili da usare con il PnP. Di conseguenza il modo di gestire il PnP nel bus ISA è complicato e richiede che il programma di PnP assegni un "handle" (identificativo) temporaneo a ciascun dispositivo PnP in modo che questi possano essere indirizzati per la successiva configurazione PnP. L'assegnazione di uno di questi "handle" è detta "isolation" (isolamento). Per i dettagli si veda ``Isolamento'' in Appendice. 3.4. Configurazione del BIOS PnP Quando un computer viene acceso, prima di caricare il sistema operativo viene eseguito il BIOS. I BIOS più recenti sono PnP e configureranno alcuni (o al limite tutti) i dispositivi PnP. In molti BIOS non c'è modo di disabilitare il PnP e quindi bisogna conviverci. Qui di seguito alcune delle scelte che potrebbero essere presenti nel menù di configurazione del proprio BIOS (talvolta detto CMOS): · ``Do you have a PnP operating system?'' · ``How are resources to be controlled?'' · ``Reset the configuration?'' 3.4.1. Do you have a PnP operating system? ("Si ha un sistema opera­ tivo PnP?") Se si risponde affermativamente, allora il BIOS PnP inizierà la configurazione PnP del disco fisso, ecc., ma lascerà che il sistema operativo termini il lavoro di configurazione. Potrebbe fare un ``Isolamento'' nel bus ISA lasciando i dispositivi pronti per essere configurati dal sistema operativo. Se il proprio sistema operativo non fa la configurazione (alcune versioni di Linux a cui è stata applicata una patch lo fanno), probabilmente non si dovrebbe rispondere affermativamente poiché il BIOS potrebbe lasciare disabilitati i dispositivi ISA ?? Se si risponde no, allora il BIOS farà tutta la configurazione da solo. A meno che non siano stati aggiunti nuovi dispositivi PnP, dovrebbe usare la configurazione precendete che ha salvato nella memoria non volatile. Se l'ultima sessione nel proprio computer è stata sotto Linux, allora non ci dovrebbero essere modifiche nella configurazione. Ma se l'ultima sessione è avvenuta in Windows 95 o 98 (che sono PnP) allora Windows potrebbe aver impostatato la configurazione diversamente da come la si vuole sotto Linux. Quanto segue non è di poco aiuto per le schede PCI, ma si può sempre controllare come sono state configurate guardando in /proc/pci. Poi si deve controllare che queste configurazioni corrispondano ai propri file di configurazione sotto Linux ("setserial", lilo.conf, ecc.) per il driver usato. Per ulteriori informazioni si veda ``Configurare il PnP dal BIOS''. 3.4.2. How are resources to be controlled? ("Come devono essere con­ trollate le risorse?") Questa scelta determina il metodo con cui si vuole siano allocati IRQ e DMA. Se impostata su "auto", il bios farà l'allocazione. Se impostata su manual, si entra in un altro menù e si sarà in grado di riservare alcuni IRQ per usarli con le schede "legacy" (non PnP). Ora il BIOS potrebbe o meno essere conscio delle schede legacy presenti. Se ne è a conoscenza, allora si provi ad usare "auto". Se non le rileva allora si riservino manualmente le IRQ necessari per le schede ISA legacy e si lasci quel che resta dell'allocazione al PnP del BIOS. Il BIOS verrà a conoscenza delle schede legacy presenti se si eseguirà ICU (o simile) sotto Windows per dirglielo. Allora il BIOS salverà queste informazioni nel sua base di dati non volatile. 3.4.3. Reset the configuration? ("Reinizializzare la configu­ razione?") Questa scelta cancellerà la base di dati del BIOS che contiene sia il modo in cui configurare i dispositivi PnP che l'elenco delle configurazioni dei dispositivi legacy (non PnP). Mai fare questa cosa a meno che non si sia convinti che tale base di dati è errata e dev'essere ricostruita. Da qualche parte è affermato che lo si dovrebbe fare solo se non si riesce ad avviare il proprio computer. Se il BIOS perde i dati sui dispositivi legacy, allora si dovrà rieseguire ICU sotto Windows per ristabilire le informazioni. 4. Come Gestire le Schede PnP 4.1. Introduzione Oggigiorno molto delle nuove schede interne sono Plug-and-Play (PnP). Alcune di queste hanno dei ponticelli (o qualcosa di simile) che possono essere postati per disabilitare il PnP. Poiché esiste del software sotto Linux (e sotto DOS/Windows) per gestire il PnP, solitamente è meglio mantenere abilitato il PnP anche se si ha l'opzione di disabilitarlo. Se si applica una patch per il Plug-and- Play al kernel, quest'ultimo non solo configurerà l'hardware mettendo le informazioni sulle risorse nei suoi registri, ma proverà pure a fornire queste informazioni al driver software cosicché non è più necessario configurarlo. Per esempio, per una porta seriale non sarà più necessario usare "setserial". Se si ha una scheda PnP, allora si hanno una o più delle seguenti opzioni per configurarla: · ``Disabilitare il PnP'' tramite i ponticelli (ma molte schede non offrono questa possibilità) o via software; · ``Configurare il PnP dal BIOS'' (solo se si ha un BIOS PnP); · ``Isapnp'' (è un programma che si può sempre usare per configurare i dispositivi PnP nel bus ISA, ma non per i dispositivi PCI); · ``Applicare una Patch al Kernel'' per trasformare Linux in un sistema operativo PnP. 4.2. Disabilitare il PnP ? Molti dispositivi sono semplicemente PnP senza la possibilità di disabilitarlo. Anche quando si ha l'opzione per farlo, si potrebbe non volerlo disabilitare per le seguenti ragioni: 1. Se si ha MS Windows nella stessa macchina, allora si vorrà permettere al PnP sotto MS Windows di configurare diversamente i dispositivi presenti. 2. L'intervallo di selezione dei numeri IRQ (o indirizzi di porta) ecc. potrebbe essere piuttosto limitato finché non si usa il PnP. 3. Se è necessario usare un software per DOS/Windows per configurare il dispositivo con il PnP disabilitato, allora un bel giorno quando si vorrà togliere finalmente di torno Dos/WIndow, ci si troverà in difficoltà nel caso si voglia cambiare la configurazione. 4. Si hanno (o si avranno) altri dispositivi PnP che devono essere configurati e quindi si deve comunque fornire il PnP. Una volta configurati come dispositivi non PnP, non possono essere configurati né da un qualsiasi software PnP né dal BIOS (finché non si spostino i ponticelli e/o si usi ancora il software di configurazione per Dos/Windows per riabilitare il PnP). 4.3. Configurare il PnP dal BIOS Ovviamente per fare questa cosa il proprio BIOS deve supportare il PnP. Per saperne di più sul proprio BIOS si veda nel web. Alcuni BIOS potrebbero avere funzioni di PnP minime e provano solamente a venire a capo, al posto delle utility per Windows, alle parti più difficili del processo di configurazione (cosa che non può succedere sotto Linux). In questo caso se il BIOS conserva una base di dati di configurazione, si potrebbe provare ad aiutare l'impostazione di questi dati usando ICU sotto DOS/Windows. Per prima cosa si imposti il BIOS per un "Sistema operativo non PnP" (o qualcosa di simile). Si veda ``Configurazione del BIOS PnP''. Ciò farà il modo che sia il BIOS a fare la configurazione invece di lasciare questo compito al sistema operativo. La base di dati non volatile del BIOS è detta ESCD (Extended System Configuration Data). La ESCD non solo immagazzina la configurazione dei dispositivi PnP, ma contiene anche le informazioni sui dispositivi non PnP in modo da evitare conflitti. Quando si installa un nuovo dispositivo non PnP si suppone che lo si dica alla ESCD del BIOS eseguendo il programma per DOS/Windows ICU (Intel Configuration Utility) prima dell'installazione. Sarà necessario eseguire questa utility anche per dire all'ESCD della presenza dei dispositivi non PnP nel PC (a meno che non l'abbia già fatto qualcun'altro). La configurazione ESCD non volatile solitamente è salvata su un chip, ma qualche volta viene messa nel disco fisso?? Ogni volta che il BIOS si avvia sotto Linux dovrebbe configurare le cose in questo modo. È bene prendere nota di come ICU (e il BIOS) hanno configurato le cose (stampandole ad esempio). Comunque, se si aggiunge un nuovo dispositivo non PnP si deve eseguire ancora il programma ICU. Se è PnP allora il BIOS lo configurerà automaticamente e teoricamente non dovrebbe cambiare la configurazione di qualsiasi altro dispositivo già presente nel sistema. Però potrebbe essere necessario riconfigurare comunque alcuni dei dispositivi presenti per poter allocare le risorse necessarie per il nuovo dispositivo. Se questo succede si deve scoprire cos'è successo (usando /proc/pci e il comando "pnpdump" degli isapnptools) e prendere l'azione appropriata. Si noti che dotto Dos/Windows la configurazione è messa anche in un file di Windows nel disco fisso in modo che il sistema operativo sappia dov'è tutto. Questo non succede in Linux perché quest'ultimo autorileva i dispositivi. 4.4. Isapnp Questo programma è solo per i dispositivi PnP sul bus ISA (non PCI). L'esecuzione del programma per Linux "isapnp" all'avvio del sistema configurerà tali dispositivi secondo i valori delle risorse specificate nel file /etc/isapnp.conf. Si avrà bisogno del pacchetto isapnptools, disponibile in molte distribuzioni di Linux. Si digiti "locate pnp" per vedere cosa si ha già disponibile per isapnp. Se la propria distribuzione installa automaticamente gli isapnptools, allora probabilmente isapnp è già automaticamente eseguito all'avvio. In questo caso, tutto quel che si deve dare è di modificare il file /etc/isapnp.conf come spiegato da "man isapnp.conf". Si noti che questa cosa è equivalente alla configurazione manuale del PnP poiché si fanno decisioni su come configurare il tutto modificando tale file di configurazione. Se si usa "isapnp" in questo modo e si ha un BIOS PnP, si dovrebbe dire al BIOS (quando lo si configura) che si ha un sistema operativo PnP ?? Se si esegue isapnp una volta per configurare i dispositivi ISA PnP, ma l'esecuzione di isapnp fallisce ogni volta che il computer viene avviato, allora se si ha MS Windows (95 o 98) sullo stesso PC la cosa potrebbe essere dovuta al seguente problema: quando si usa MS Windows (95 o 98), Windows potrebbe configurare diversamente le schede PnP in modo tale che non funzioneranno correttamente (se non del tutto) quando si torna in Linux. 4.5. Applicare una Patch al Kernel per Rendere Linux PnP Esiste una grossa patch per fare questa cosa. Il kernel risultante è stabile e include della documentazione: serial.txt per vedere come gestire le porte seriali. Fornisce "file" nell'albero /proc in modo che si può vedere cosa succede e si posso inviare comandi in questi file per una configurazione personalizzata. Un problema è che molti driver di dispositivo non riconoscono questa nuova feature, e quindi probabilmente sarà necessario usare ancora i vecchi file di configurazione, ecc. per la configurazione. Si veda 4.6. Software e Documentazione sul PnP · Si veda per puntatori a software e documentazione sul PnP. · Si veda per puntatori alle specifiche del Pnp. 5. Appendice 5.1. Indirizzi Esistono tre tipi di indirizzi: indirizzi nella memoria principale, indirizzi I/O e indirizzi di configurazione (solo nel bus PCI). In questo documento il termine "indirizzo" alcune volte è stato usato per indicare un intervallo di indirizzi contigui. Poiché gli indirizzi sono dati in byte, un indirizzo singolo contiene un solo byte, ma gli indirizzi I/O (e della memoria principale) hanno bisogno di molto più di questo. Quindi spesso sono usati indirizzi di 8 byte per gli indirizzi di I/O mentre gli intervalli allocati per gli indirizzi nella memoria principale sono molto più grandi. Per una porta seriale (un dispositivo di I/O) è sufficiente specificare l'indirizzo di I/O di partenza del dispositivo (come 3f8) in quanto è ben noto che l'intervallo di indirizzi per questo dispositivo è di soli 8 byte. L'indirizzo di partenza è noto come "indirizzo base" ("base address"). Per accedere ad entrambi gli "spazi" di indirizzi di I/O e di memoria (principale) è usato lo stesso bus indirizzi (le linee usate per gli indirizzi sono condivise) Come fa un dispositivo a sapere quando un indirizzo che appare nel bus indirizzi è un indirizzo di memoria o un indirizzo I/O? Beh, ci sono 4 linee dedicate sul bus che trasportano questa ed altre informazioni. Se una ben determinata di queste è in un certo stato, indica che la CPU vuole leggere da un indirizzo di I/O e la memoria principale ignora l'indirizzo nel bus. In sostanza: esistono linee di lettura (read) e scrittura (write) sia per la memoria principale che per l'I/O (4 linee in tutto). Tradizionalmente, la maggior parte dei dispositivi di I/O usano solo la memoria di I/O per comunicare con la CPU. Per esempio, la porta seriale lo fa. Il driver del dispositivo, in esecuzione nella CPU legge e scrive dati da e nello spazio spazio di indirizzi I/O e solitamente li mette nella memoria principale. Un modo più veloce è che il dispositivo metta direttamente i dati nella memoria principale. Un modo per farlo è di usare i ``Canali DMA''. Un'altro modo è di allocare al dispositivo un po' di spazio nella memoria principale. In questo modo il dispositivo legge e scrive direttamente nella memoria principale senza preoccuparsi del DMA. Tali dispositivi solitamente hanno sia indizzi di I/O che indirizzi in memoria principale. 5.2. Interrupt -- Dettagli Gli interrupt trasportano un sacco di informazioni, ma solo indirettamente. Il segnale di interrupt (una tensione in una linea) dice semplicemente ad un chip chiamato interrupt controller ("controllore delle interruzioni") che un certo dispositivo chiede un po' di attenzione. L'interrupt controller allora lo segnala alla CPU. La CPU esegue un programma speciale (parte del software di gestione del dispositivo) noto come "interrupt service routine". Questa "routine" prova a capire cos'è successo e poi si occupa del problema, come il trasferimento di dati da (o nel) dispositivo. Questo programma (routine) può facilmente scoprire cos'è successo in quanto il dispositivo ha dei registri ad un indirizzo noto al software di gestione (premesso che le informazioni sul numero IRQ e l'indirizzo di I/O siano impostate correttamente). Questi registri contengono informazioni sullo stato del dispositivo. Il software legge il contenuto di questi registri e ispezionandone il contenuto, scopre cos'è successo e intraprende l'azione appropriata. 5.3. Isolamento Questa cosa è pertinente solo con il bus ISA. L'isolamento ("isolation") è un complesso metodo per assegnare un handle temporaneo (numero identificativo) ad ogni dispositivo PnP presente nel bus ISA. Sebbene esistano modi molto più efficienti (ma più complessi) per fare questa cosa, alcuni affermano che questo è un metodo semplice. È usato solo un indirizzo di scrittuta per tutte le scritture PnP a tutti i dispositivi PnP, cosicché quello che viene scritto in questo indirizzo va a tutti i dispositivi PnP che sono in ascolto. Questo indirizzo di scrittura è usato per inviare (assegnare) un handle unico ad ognuno dei dispositivi PnP. Questa assegnazione richiede che solo un dispositivo sia in attesa quando è inviato (scritto) l'handle in questo indirizzo comune. Tutti i dispositivi PnP hanno un numero di serie unico che usano per il processo di isolamento. Fare l'isolamento è qualcosa di simile ad un gioco. È fatto usando l'equivalente di una sola linea del bus che collega tutti i dispositivi PnP e il programma di isolamento. Nel primo giro di questo "gioco" tutti i dispositivi PnP sono ascolto su questa linea e inviano simultaneamente una sequenza di bit nella linea. I bit permessi sono un "1" (tensione positiva) oppure uno "0 aperto" di nessuna tensione (circuito aperto e tri-state). Ogni dispositivo PnP inizia semplicemente ad inviare sequenzialmente su questa linea il suo numero di serie, bit a bit, iniziando con il bit più significativo. Se un qualsiasi dispositivo, invia un 1, un 1 sarà sentito sulla linea da tutti gli altri dispositivi. Se tutti i dispositivi inviano uno "0 aperto" nella linea non si sentirà niente. L'obbiettivo è di eliminare (alla fine di questa prima tornata) tutti i dispositivi tranne quello con il numero di serie più elevato (si noti che tutti i numeri di serie sono della stessa lunghezza). Per prima cosa si consideri solo il bit più significativo. Se un qualsiasi dispositivo PnP invia uno 0 (0 aperto) ma sente un 1, questo significa che qualche altro dispositivo PnP ha un numero di serie più alto, e quindi temporaneamente si toglie dal gioco e non ascolta più finché il giro non è terminato (ovvero quando viene assegnato un handle al vincitore: il dispositivo con il numero di serie più alto). Ora i dispositivi ancora in gioco hanno tutti lo stesso bit più significativo (un 1), e quindi, per la partecipazione futura a questo giro, possiamo trascurare questa cifra e considerare solo la parte rimanente del numero di serie. Adesso si torni all'inizio di questo paragrafo e lo si ripeta finché per tutti i dispositivi non siano stati esaminati completamente i numeri di serie (si veda sotto per il caso di tutti 0). Cosa succede se le cifre più significative (anche nel caso dei numeri di serie ridotti) sono tutte 0? In questo caso è stato inviato uno "0 aperto" nella linea e tutti i partecipanti rimangono in gioco. Se tutti hanno uno 0 come cifra più significativa allora gli 0 sono trascurati come è stato fatto nel paragrafo precedente con gli 1. Il gioco continua inviando la cifra successiva del numero di serie. Alla fine di questa tornata (dopo che ogni partecipante rimasto ha inviato il bit meno significato del numero di serie) rimane solo il dispositivo PnP con il numero di serie più elevato. A questo viene asseganto un handle ed esce permanentemente dal gioco. Poi tutti quelli scartati precedentemente rientrano in gioco e inizia un nuovo giro con un partecipante in meno. Alla fine, viene assegnato un handle a ciascun dispositivo PnP. È facile vedere che questo algoritmo funziona. Una volta assegnati, gli handle sono usati per indirizzare ogni dispositivo PnP, sia per potergli inviare una configurazione sia per leggere le informazioni di configurazione dal dispositivo stesso. Si noti che questi handle sono usati solo per la configurazione PnP e non sono usati per le normali comunicazioni con il dispositivo. Quando il computer viene avviato, tutti gli handle sono stati persi e quindi il BIOS solitamente opera il processo di isolamento ogniqualvolta si riavvia il proprio PC.