<tt/kerneld/ mini-HOWTO <author>Henrik Storner, <htmlurl url="mailto:storner@osiris.ping.dk" name="<storner@osiris.ping.dk>"> <date>v1.7, 19 luglio 1997 <abstract> Questo documento spiega come puoi usare la funzione <tt/kerneld/ nei kernel di Linux. L'ultima versione rilasciata di questo documento la puoi trovare all'indirizzo <url url="http://eolicom.olicom.dk/~storner/kerneld-mini-HOWTO.html">. Dopo ogni pubblicazione di questo mini-HOWTO puoi trovare degli aggiornamenti nella mia lista disordinata dei cambiamenti all'indirizzo <url url="http://eolicom.olicom.dk/~storner/kern.html">. Traduzione di Lorenzo Cappelletti, <htmlurl url="mailto:L.Cappelletti@POBoxes.com" name="<L.Cappelletti@POBoxes.com>">. </abstract> <toc> <sect>Ringraziamenti Se dovessi trovare delle cose sbagliate in questo documento, ti pregherei di farmelo sapere. Le seguenti persone hanno contribuito per questo mini-HOWTO in alcuni punti: <itemize> <item>Bjorn Ekwall <bj0rn@blox.se> <item>Ben Galliart <bgallia@luc.edu> <item>Cedric Tefft <cedric@earthling.net> <item>Brian Miller <bmiller@netspace.net.au> <item>James C. Tsiao <jtsiao@madoka.jpl.nasa.gov> </itemize> Ho apprezzato molto gli incoraggiamenti ed i suggerimenti che mi hanno spedito i lettori di questo mini-HOWTO. <sect>Preliminari <sect1>Cos'è <tt/kerneld/?<label id="Introduction"> <tt/kerneld/ è una caratteristica introdotta durante lo sviluppo dei kernel 1.3 da <url url="mailto:bj0rn@blox.se" name="Bjorn Ekwall">. Viene acclusa con tutti i kernel delle versioni 2.0 e 2.1. Permette ai «moduli» del kernel (cioé driver di periferica, driver di rete, <sl/filesystem/) di venir caricati automaticamente quando c'è bisogno, invece di doverlo fare manualmente con <tt/modprobe/ o <tt/insmod/. E per motivi piú divertenti, nonostante questi non siano (ancora?) integrati con il kernel standard: <itemize> <item>può essere impostato per lanciare un programma, invece del solito schermo nero, permettendoti cosí di usare ogni programma come uno <sl/screen-saver/; <item>similmente al supporto dell'oscuramento dello schermo, puoi anche cambiare il «beep» di console in qualche cosa di completamente differente... </itemize> <tt/kerneld/ consiste di due entità separate: <itemize> <item>un supporto nel kernel di Linux che permette di inviare delle richieste ad un demone, affinché sappia che un modulo è necessario per una certa operazione; <item>un demone a livello utente che capisca quali moduli devono essere caricati per soddisfare alle richieste del kernel. </itemize> Entrambe le parti dovranno lavorare per far funzionare il supporto <tt/kerneld/. Non è sufficiente che ne sia configurata una sola. <sect1>Perché avrei bisogno di usarlo?<label id="Why"> Ci sono alcune buone ragioni per usare <tt/kerneld/. Quelle che menzionerò sono le mie, gli altri potrebbero volerlo usare per altri motivi. <itemize> <item>Se devi compilare kernel per svariati sistemi che si distinguono di poco (differenti tipi di schede di rete, per esempio), puoi preparare un singolo kernel e alcuni moduli invece di essere costretto a compilare un kernel per ogni sistema. <item>I moduli sono piú facili da provare per gli sviluppatori (non c'è bisogno di ravviare il sistema per caricare e scaricare i driver). Questo vale per tutti i moduli, non solo per quelli caricati da <tt/kerneld/. <item>Limita l'utilizzo di memoria da parte del kernel, cioé hai piú memoria disponibile per le applicazioni. La memoria usata dal kernel non è <bf/mai/ trasferita alla memoria di <sl/swap/, cosí se ci sono 100kB di driver inutilizzati compilati nel kernel, questi sono semplicemente RAM sprecata. <item>Alcune delle cose che uso (il driver per l'unità a nastro, per esempio, o l'iBCS) sono solo disponibili come moduli. Ma non voglio scocciarmi con il loro caricamento e scaricamento ogni volta che ne ho bisogno. <item>Le persone che curano le distribuzioni Linux non devono compilare 284 differenti immagini di boot: ogni utente carica i driver di cui ha bisogno per il suo hardware. Questo è usato, per esempio, dalla RedHat 4.0 nella sua installazione. </itemize> Certo, ci sono anche ragioni per le quali potresti non volerlo usare (potresti preferire un unico file d'immagine per il kernel con tutti i tuoi driver compilati staticamente). In questo caso stai leggendo il documento sbagliato. <sect1>Dove posso prelevare i componenti necessari?<label id="Where"> Il supporto nel kernel di Linux fu introdotto con Linux 1.3.57. Se hai una versione di kernel precedente, avrai bisogno di aggiornarla se vuoi il supporto per <tt/kerneld/. Tutti i maggiori siti ftp di Linux contengono i sorgenti del kernel. Ti raccomando di aggiornarti all'ultima versione stabile, 2.0, ora a livello di <sl/patch/ 29: <itemize> <item><url url="ftp://sunsite.unc.edu/pub/Linux/kernel/v2.0/">linux-2.0.29.tar.gz <item><url url="ftp://tsx-11.mit.edu/pub/linux/sources/system/v2.0/">linux-2.0.29.tar.gz <item><url url="ftp://ftp.funet.fi/pub/OS/Linux/PEOPLE/Linus/v2.0/">linux-2.0.29.tar.gz </itemize> Il demone a livello utente è incluso nel pacchetto modules-1.2.8 e con il piú aggiornato modules-2.0. Questi sono normalmente disponibili dallo stesso sito in cui avete trovato i sorgenti del kernel, mentre i siti ufficiali includono: <itemize> <item><url url="ftp://sunsite.unc.edu/pub/Linux/kernel/">/modules-2.0.0.tar.gz <item><url url="ftp://tsx-11.mit.edu/pub/linux/sources/sbin/">modules-2.0.0.tar.gz <item><url url="ftp://ftp.funet.fi/pub/OS/Linux/tools/">modules-2.0.0.tar.gz </itemize> <bf/NOTA/: se vuoi provare a caricare i moduli con gli ultimi kernel 2.1 in fase di <bf/sviluppo/, devi procurarti il pacchetto modutils- (NON modules-). Comunque <ref id="2-1-problems" name="vedi piú avanti"> per i problemi che si possono avere con i moduli ed il kernel 2.1. <sect>Cominciamo a fare sul serio <sect1>Come impostare il tutto?<label id="Setup"> Primo procurarsi i componenti necessari: un kernel adatto e le ultime utility per i moduli. Poi devi installarle. Molto semplice: decomprimi i sorgenti e lancia <tt/make install/. Questo compila e installa in <tt>/sbin</tt> i seguenti programmi: genksysm, insmod, lsmod, modprobe, depmod, kerneld. Ti raccomando di aggiungere le seguenti linee ai tuoi script di avvio che effettuano alcune impostazioni necessarie ogni volta che Linux viene avviato. Aggiungi le seguenti linee al tuo file <tt>/etc/rc.d/rc.S</tt> (se utilizzi Slackware) o a <tt>/etc/rc.d/rc.sysinit</tt> (se utilizzi SysVinit, cioé Debian, RedHat, Caldera): <tscreen><verb> # Lancia kerneld - questo deve accadere molto presto nel processo # di boot, sicuramente PRIMA che venga avviato fsck sui filesystem, # in quanto potrebbe richiedere l'autocaricamento di qualche driver if [ -x /sbin/<tt/kerneld/ ] then /sbin/<tt/kerneld/ fi # I comandi fsck standard vanno qui # assieme al comando mount per montare il fs in lettura-scrittura # Aggiornamento del file per le dipendenze kernel-moduli # Il fs root ora DEVE essere montato in lettura-scrittura if [ -x /sbin/depmod ] then /sbin/depmod -a fi </verb></tscreen> La prima parte lancia <tt/kerneld/. La seconda parte chiama <tt/depmod -a/ all'avvio. Il programma depmod costruisce una lista di moduli disponibili e analizza le loro inter-dipendenze, cosí si sa se, per un modulo che sta per essere caricato, è necessario caricarne un altro prima. <bf/Nota/: nelle recenti versioni di <tt/kerneld/ c'è la possibilità di fare il link verso le librerie GNU dbm, libgdbm. Se abiliti questa opzione quando compili le utility per i moduli, <it><tt/kerneld/ non partirà se libgdbm non è disponibile</it>, caso che potrebbe accadere se hai <tt>/usr</tt> su una partizione separata e fai partire <tt/kerneld/ prima che <tt>/usr</tt> sia montata. La soluzione consigliata è di spostare libgdbm da <tt>/usr/lib</tt> a <tt>/lib</tt> o linkarla staticamente a <tt/kerneld/. Successivamente decomprimi i sorgenti del kernel, configuralo e compilane uno che ti soddisfi. Se non lo hai mai fatto prima, devi definitivamente leggerti il file README che si trova al primo livello dei sorgenti di Linux. Quando lanci <tt/make config/ per configurare il kernel, devi prestare attenzione ad alcune domande che appaiono verso l'inizio: <tscreen><verb> Enable loadable module support (CONFIG_MODULES) [Y/n/?] Y </verb></tscreen> Hai bisogno di selezionare il supporto per i moduli caricabili o non ci saranno moduli per <tt/kerneld/ da caricare! Rispondi con <sl/Yes/. <tscreen><verb> Kernel daemon support (CONFIG_KERNELD) [Y/n/?] Y </verb></tscreen> Anche questo, ovviamente, è necessario. A questo punto molte delle cose nel kernel possono essere compilate come moduli. Vedrai domande come: <tscreen><verb> Normal floppy disk support (CONFIG_BLK_DEV_FD) [M/n/y/?] </verb></tscreen> dove puoi rispondere con una «M» che sta per «Modulo». Generalmente solo i driver necessari per far partire il sistema (il driver per l'hard-disk, il driver per il <sl/filesystem/ principale) dovrebbero essere compilati nel kernel; gli altri possono essere compilati come moduli. Una volta finito con <tt/make config/, lancia <tt/make dep/, <tt/make clean/, <tt/make zImage/ o <tt/make zlilo/, <tt/make modules/ e <tt/make modules_install/. Uff! Il comando <tt/make zImage/ mette la nuova immagine del kernel nel file <tt>/arch/i386/boot/zImage</tt>. Avrai bisogno di copiarla dove tieni la tua immagine di boot o di configurare LILO in seguito. Per maggiori informazioni su come configurare, compilare e installare il tuo kernel, dai un'occhiata al <url url="http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html" name="Kernel-HOWTO">, postato regolarmente in comp.os.linux.answers e disponibile su sunsite.unc.edu in /pub/Linux/docs/HOWTO. <sect1>Proviamo <tt/kerneld/<label id="Testing"> Ora fai il reboot con il nuovo kernel. Quando il sistema è di nuovo pronto, puoi lanciare un <tt/ps -ax/ con il quale dovresti vedere una linea dedicata a <tt/kerneld/: <tscreen><verb> PID TTY STAT TIME COMMAND 59 ? S 0:01 /sbin/kerneld </verb></tscreen> Una delle cose carine con <tt/kerneld/ è che, una volta che hai installato il kernel e il demone, poche impostazioni sono ancora necessarie. Per un inizio prova ad usare uno dei driver che hai compilato come modulo (in generale tutto funziona senza ulteriori configurazioni). Io ho compilato il driver per il floppy come modulo, cosí posso mettere un dischetto DOS nel drive e <tscreen><verb> osiris:~ $ mdir a: Volume in drive A has no label Volume Serial Number is 2E2B-1102 Directory for A:/ binuti~1 gz 1942 02-14-1996 11:35a binutils-2.6.0.6-2.6.0.7.diff.gz libc-5~1 gz 24747 02-14-1996 11:35a libc-5.3.4-5.3.5.diff.gz 2 file(s) 26689 bytes </verb></tscreen> Cosí il driver del floppy funziona: viene caricato automaticamente da <tt/kerneld/ quando provo ad usare il disco floppy. Per vedere, invece, che il modulo del floppy viene effettivamente caricato, puoi lanciare <tt>/sbin/lsmod</tt> che lista tutti i moduli attualmente caricati: <tscreen><verb> osiris:~ $ /sbin/lsmod Module: #pages: Used by: floppy 11 0 (autoclean) </verb></tscreen> L'«autoclean» sta ad indicare che il modulo verrà automaticamente rimosso da <tt/kerneld/ dopo che questo non viene usato per piú di un minuto. Cosí le 11 pagine di memoria (=44kB, una pagina è 4kB) verranno utilizzate solo quando accedo al drive del floppy (se non uso il floppy per piú di un minuto, verranno liberate). Alquanto carino, se sei a corto di memoria per le tue applicazioni! <sect>Come fa <tt/kerneld/ a sapere quale modulo caricare? <label id="Configuration"> Nonostante <tt/kerneld/ ci venga fornito con informazioni già pronte sui tipi piú comuni di moduli, ci sono situazioni in cui <tt/kerneld/ non saprà come trattare una richiesta del kernel. Questo accade per moduli tipo il driver per il CD-ROM o i driver di rete, dove ci sono piú di un modulo da poter caricare. Le richieste che il demone <tt/kerneld/ riceve dal kernel possono appartenere ad uno dei seguenti tipi: <itemize> <item><ref id="blockdev" name="driver di periferica a blocchi"> <item><ref id="chardev" name="driver di periferica a caratteri"> <item><ref id="binfmt" name="formato binario"> <item><ref id="ldisc" name="disciplinea di linea tty"> <item><sl/<ref id="fs" name="filesystem">/ <item><ref id="eth0" name="periferica di rete"> <item>servizio di rete (per esempio rarp) <item><ref id="net-pf" name="protocollo di rete"> (per esempio IPX) </itemize> <tt/kerneld/ determina quale modulo dovrebbe essere caricato cercando nel file di configurazione <tt>/etc/conf.modules</tt>. Ci sono due tipi di voci possibili in questo file: <it/path/ (dove si trovano i file dei moduli) e <it/alias/ (quale modulo dovrebbe essere caricato). Se non hai già questo file, dovresti crearlo con il comando: <tscreen><verb> /sbin/modprobe -c | grep -v '^path' > /etc/conf.modules </verb></tscreen> Se vuoi aggiungere un'altra direttiva «path» ai percorsi di default, <bf/devi anche includere tutti gli altri percorsi di «default»/, in quanto una direttiva «path» in <tt>/etc/conf.modules</tt> <bf/rimpiazzerà/ tutti quelli che modprobe conosce per default! Normalmente non avrai bisogno di aggiungere alcun percorso, in quanto l'insieme di quelli precompilati dovrebbe essere sufficiente per tutte le configurazioni «normali» (ed altre ancora...). Promesso! Diversamente, se vuoi aggiungere un «alias» o una direttiva «option», le nuove voci in <tt>/etc/conf.modules</tt> verranno <bf/aggiunte/ a quelle che modprobe già conosce. Se devi <bf/ridefinire/ un «alias» o «options», le nuove voci in <tt>/etc/conf.modules</tt> sovrascriveranno quelle precompilate. <sect1>Periferiche a blocchi<label id="blockdev"> Se esegui <tt>/sbin/modprobe -c</tt>, otterrai una lista di moduli che <tt/kerneld/ conosce, e di richieste alle quali questi corrispondono. Per esempio, la richiesta che termina con il caricamento del driver del floppy è (per una periferica a blocchi che ha un <sl/major number/ pari a 2): <tscreen><verb> osiris:~ $ /sbin/modprobe -c | grep floppy alias block-major-2 floppy </verb></tscreen> Perché block-major-2? Perché le periferiche floppy <tt>/dev/fd*</tt> usano una periferica con <sl/major/ di 2 e sono periferiche a blocchi: <tscreen><verb> osiris:~ $ ls -l /dev/fd0 /dev/fd1 brw-rw-rw- 1 root root 2, 0 Mar 3 1995 /dev/fd0 brw-r--r-- 1 root root 2, 1 Mar 3 1995 /dev/fd1 </verb></tscreen> <sect1>Periferiche a caratteri<label id="chardev"> Le periferiche a caratteri sono trattate in modo analogo. Per esempio il driver per l'unità a nastro connessa come floppy ha un <sl/major/ di 27: <tscreen><verb> osiris:~ $ ls -lL /dev/ftape crw-rw---- 1 root disk 27, 0 Jul 18 1994 /dev/ftape </verb></tscreen> Però <tt/kerneld/ non conosce per default il driver dell'unità a nastro. Infatti non è presente nella lista ottenuta da <tt>/sbin/modprobe -c</tt>. Cosí per impostare <tt/kerneld/ affinché carichi il driver per l'unità a nastro, si deve aggiungere una linea al file di configurazione di <tt/kerneld/ <tt>/etc/conf.modules</tt>: <tscreen><verb> alias char-major-27 ftape </verb></tscreen> <sect1>Periferiche di rete<label id="eth0"> Puoi anche usare il nome della periferica al posto di impostazioni come «char-major-<it/xxx/» o «block-major-<it/yyy/». Questo è particolarmente utile per i driver di rete. Per esempio un driver per una scheda di rete tipo ne2000 abilitata come eth0 verrebbe caricato con <tscreen><verb> alias eth0 ne </verb></tscreen> Se hai la necessità di passare alcune opzioni al driver (per esempio per informare il modulo su quale IRQ la scheda di rete sta usando) aggiungi una linea «options»: <tscreen><verb> options ne irq=5 </verb></tscreen> Questo farà in modo che <tt/kerneld/ carichi il driver NE2000 con il comando: <tscreen><verb> /sbin/modprobe ne irq=5 </verb></tscreen> Ovviamente le opzioni effettivamente disponibili sono specifiche al modulo che caricherai. <sect1><sl/Formati degli eseguibili/<label id="binfmt"> I formati binari sono trattati in modo simile. Ogni volta che provi a lanciare un programma che <tt/kerneld/ non sa come caricare, <tt/kerneld/ riceve una richiesta per «binfmt-<it/xxx/», dove <it/xxx/ è il numero determinato dai primi byte dell'eseguibile. Cosí la configurazione di <tt/kerneld/ per supportare il modulo <tt/binfmt_aout/ per gli eseguibili ZMAGIC (a.out) è: <tscreen><verb> alias binfmt-267 binfmt_aout </verb></tscreen> in quanto il <sl/magic number/ (vedi <tt>/etc/magic</tt>) per file ZMAGIC è 267. (Se provi a controllare <tt>/etc/magic,</tt> vedrai il numero 0413, ma <tt>/etc/magic</tt> usa numeri ottali, mentre <tt/kerneld/ li usa decimali, e ottale 413 = decimale 267). In realtà ci sono tre varianti leggermente diverse per gli eseguibili a.out (NMAGIC, QMAGIC and ZMAGIC), cosí per un pieno supporto del modulo binfmt_aout abbiamo bisogno di: <tscreen><verb> alias binfmt-264 binfmt_aout # eseguibile puro (NMAGIC) alias binfmt-267 binfmt_aout # eseguibile demand-paged (ZMAGIC) alias binfmt-204 binfmt_aout # eseguibile demand-paged (QMAGIC) </verb></tscreen> I formati binari a.out, Java e iBCS sono riconosciuti automaticamente da <tt/kerneld/, senza alcuna configurazione. <sect1>Disciplinea di linea (slip, cslip e ppp)<label id="ldisc"> Le disciplinee di linea sono richieste con «tty-ldisc-<it/x/», dove <it/x/ assume solitamente i valori 1 (per SLIP) o 3 (per PPP). Entrambi sono riconosciuti da <tt/kerneld/ automaticamente. A proposito di ppp, se vuoi che <tt/kerneld/ carichi il modulo bsd_comp per la compressione dei dati per il ppp, allora devi aggiungere le due linee seguenti al tuo <tt>/etc/conf.modules</tt>: <tscreen><verb> alias tty-ldisc-3 bsd_comp alias ppp0 bsd_comp </verb></tscreen> <sect1>Famiglie di protocolli di rete (IPX, AppleTalk, AX.25) <label id="net-pf"> Anche alcuni protocolli di rete possono essere caricati come moduli. Il kernel domanda a <tt/kerneld/ di una famiglia di protocolli (per esempio IPX) con una richiesta del tipo «net-pf-<it/x/», dove <it/x/ è un numero che sta ad indicare la famiglia voluta. Per esempio net-pf-3 è AX.25, net-pf-4 è IPX e net-pf-5 è AppleTalk (questi numeri sono determinati dalle definizioni AF_AX25, AF_IPX, etc. nel file sorgente di Linux <tt>include/linux/socket.h</tt>). <tscreen><verb> alias net-pf-4 ipx </verb></tscreen> Dai un'occhiata anche alla sezione riguardante i <ref id="CommonProblems" name="problemi comuni"> per informazioni su come evitare alcuni noiosi messaggi all'avvio relativi a famiglie di protocolli indefiniti. <sect1>File system<label id="fs"> Le richieste di <tt/kerneld/ per i <sl/filesystem/ sono semplicemente i nomi dei <sl/filesystem/. Un tipico uso potrebbe essere quello di caricare il modulo isofs per i <sl/filesystem/ del CD-ROM, cioé per <sl/filesystem/ di tipo «iso9660»: <tscreen><verb> alias iso9660 isofs </verb></tscreen> <sect>Periferiche che richiedono una configurazione speciale <label id="special-devs"> Alcune periferiche richiedono una configurazione che va leggermente al di là del semplice uso di «alias» del tipo <it/periferica-modulo/. <itemize> <item>periferiche a caratteri con <sl/major number/ 10: <ref id="miscdevs" name="Periferiche varie"> <item><ref id="scsidevs" name="periferiche SCSI"> <item><ref id="pre_post" name="periferiche che richiedono inizializzazioni speciali"> </itemize> <sect1><sl/char-major-10/: mouse, <sl/watchdog/ e <sl/ random/ <label id="miscdevs"> Le periferiche hardware sono usualmente identificate con il loro <sl/major number/, cosí per l'unità a nastro si ha un <sl/char-major-27/. Ciò nonostante, se scorri le voci presenti in <tt>/dev</tt> che contengono il <sl/char-major-10/, vedrai che queste formano un bel gruppo di periferiche molto diverse fra loro: <itemize> <item>mouse di vari tipi (<it/bus mouse/, mouse PS/2) <item>periferiche <sl/watchdog/ <item>la periferica del kernel «<sl/random/» <item>interfaccia APM (Advanced Power Management) </itemize> Ovviamente queste periferiche sono controllate da altrettanti moduli differenti, non da uno solo. Perciò la configurazione di <tt/kerneld/ per queste <bf/periferiche eterogenee/ fa uso del <sl/major number/ <bf/e/ del <sl/minor number/: <tscreen><verb> alias char-major-10-1 psaux # per mouse PS/2 alias char-major-10-130 wdt # per il watchdog WDT </verb></tscreen> Hai bisogno di una versione del kernel 1.3.82 o superiore per poter utilizzare questa caratteristica; le versioni precedenti non passano il <sl/minor number/ a <tt/kerneld/, impedendogli di capire quale modulo di periferica caricare. <sect1>Caricamento di driver SCSI: la voce <sl/ scsi_hostadapter/<label id="scsidevs"> I driver per le periferiche SCSI consistono in un driver per l'adattatore SCSI (per esempio un Adaptec 1542) e di un driver per il tipo di periferica SCSI che usi (per esempio un hard-disk, un CD-ROM o un'unità a nastro). Tutti questi possono essere caricati come moduli. Perciò, quando vuoi accedere, per esempio, al lettore di CD-ROM connesso alla scheda Adaptec, il kernel e <tt/kerneld/ sanno solo che c'è bisogno di caricare il modulo <it/sr_mod/ per supportare il CD-ROM SCSI, ma non sanno a quale controller il CD-ROM è connesso né, tanto meno, quale modulo caricare per supportare il controller SCSI. Per risolvere questo problema puoi aggiungere una voce per il driver SCSI al tuo <tt>/etc/conf.modules</tt> che dica a <tt/kerneld/ quale dei possibili moduli per controller SCSI deve caricare: <tscreen><verb> alias scd0 sr_mod # sr_mod per CD-ROM SCSI... alias scsi_hostadapter aha1542 # ...necessitano del driver Adaptec </verb></tscreen> Questo funziona solo con versioni del kernel 1.3.82 o superiori. Il metodo va bene se hai un solo controller SCSI. Se ne hai piú d'uno, le cose diventano un po' piú difficili. In generale non puoi lasciare che <tt/kerneld/ carichi un driver per un adattatore SCSI se un driver per un altro adattatore SCSI è già installato. Sei costretto a compilare entrambi i driver direttamente nel kernel (non come moduli) o caricare i moduli manualmente. Anche se un modo per caricare piú driver SCSI <it/c'è/. James Tsiao ha avuto questa idea: <quote> Puoi facilmente fare in modo che <tt/kerneld/ carichi il secondo driver scsi impostando le dipendenze in <tt/modules.dep/ a mano. Hai bisogno solo di una voce come: <tscreen><verb> /lib/modules/2.0.30/scsi/st.o: /lib/modules/2.0.30/scsi/aha1542.o </verb></tscreen> per far caricare a <tt/kerneld/ aha1542.o prima che carichi st.o. La mia macchina a casa è configurata praticamente come sopra e tutto funziona bene per le mie periferiche scsi secondarie, inclusa l'unità a nastro, il CD-ROM e periferiche scsi generiche. La controparte sta nel fatto che <tt>depmod -a</tt> non può rilevare automaticamente queste dipendenze, cosí l'utente ha bisogno di aggiungerle manualmente e non può lanciare <tt>depmod -a</tt> all'avvio. Ma, una volta che tutto è configurato, <tt/kerneld/ caricherà in automatico l'aha1542.o senza problemi. </quote> Dovresti essere conscio che questa tecnica funziona solo se hai tipi diversi di periferiche SCSI collegate ai due controller (per esempio degli hard-disk su un controller e lettori CD-ROM, unità a nastro o periferiche SCSI generiche sull'altro). <sect1>Quando caricare un modulo non è abbastanza: la voce 'post-install' <label id="pre_post"> Qualche volta caricare solo il modulo non è abbastanza per far funzionare le cose. Per esempio, se hai compilato la scheda sonora come modulo, spesso è conveniente impostare un certo livello per il volume. L'unico problema è che l'impostazione svanisce quando viene caricato il modulo un'altra volta. Ecco, in breve, un trucco di <url url="mailto:bgallia@luc.edu" name="Ben Galliart">: <quote> La soluzione definitiva richiesta dall'installazione del pacchetto <url url="ftp://sunsite.unc.edu/pub/Linux/apps/sound/mixers/setmix-0.1.tar.gz" name="setmix-0.1">. E poi aggiungendo le seguenti linee al mio <tt>/etc/conf.modules</tt>: <tscreen><verb> post-install sound /usr/local/bin/setmix -f /etc/volume.conf </verb></tscreen> </quote> Questa linea fa in modo che <tt/kerneld/, dopo che il modulo per l'audio è stato caricato, lanci il comando indicato dalla voce «post-install sound». Cosí il modulo sonoro viene configurato con il comando <tt>/usr/local/bin/setmix -f /etc/volume.conf</tt>. Ciò può essere utile anche per altri moduli, per esempio il modulo lp può essere configurato con il programma tunelp aggiungendo: <tscreen><verb> post-install lp tunelp <options> </verb></tscreen> Affinché <tt/kerneld/ recepisca queste opzioni, hai bisogno di una versione di <tt/kerneld/ che sia la 1.3.69f o superiore. <bf/Nota/: una versione recente di questo mini-HOWTO parlava di un'opzione «pre-remove», che si sarebbe potuta usare per eseguire un comando appena prima che <tt/kerneld/ rimuovesse un modulo. Ciò nonostante questa opzione non ha mai funzionato e il suo uso è perciò scoraggiato (piú appropriatamente, questa opzione scomparirà in una <sl/release/ futura di <tt/kerneld/). L'intera struttura delle «impostazioni» per un modulo sta subendo alcuni cambiamenti in questo momento e potrebbe essere diversa sul tuo sistema quando leggerai questo documento. <sect>Spiare <tt/kerneld/<label id="Spying"> Se hai provato qualsiasi cosa e non sei proprio capace di immaginare cosa il kernel stia chiedendo di fare a <tt/kerneld/, c'è un modo di vedere le richieste che <tt/kerneld/ riceve e, da questo, capire cosa deve andare in <tt>/etc/conf.modules</tt>: l'utility kdstat. Questo piccolo e grazioso programma fa parte del pacchetto dei moduli, ma non viene compilato né installato per default. Per ottenerlo: <tscreen><verb> cd /usr/src/modules-2.0.0/kerneld make kdstat </verb></tscreen> Poi, per fare in modo che <tt/kerneld/ mostri informazioni su cosa sta facendo, lancia <tscreen><verb> kdstat debug </verb></tscreen> e <tt/kerneld/ comincerà a vomitare messaggi sulla <sl/console/ dicendoti di cosa sta facendo. Se poi provi ad eseguire il comando che vuoi utilizzare, vedrai comparire le richieste di <tt/kerneld/; queste possono essere messe in <tt>/etc/conf.modules</tt> utilizzando un sinonimo per il modulo necessario a completare il lavoro. Per fermare la fase di <sl/debug/, lancia <tt>/sbin/kdstat nodebug</tt>. <sect>Usi particolari di <tt/kerneld/<label id="Goodies"> Lo sapevo che volevi chiedere come impostare il modulo per lo screen-saver... La directory <tt><tt/kerneld//GOODIES</tt> nel pacchetto dei moduli ha un paio di <sl/patch/ per il supporto di <tt/kerneld/ di screen-saver e beep della <sl/console/; queste non fanno ancora parte del kernel ufficiale. Cosí avrai bisogno di installarle e ricompilare il kernel. Per installare una <sl/patch/ si usa il comando <tt/patch/: <tscreen><verb> cd /usr/src/linux patch -s -p1 < /usr/src/modules-2.0.0/<tt/kerneld//GOODIES/blanker_patch </verb></tscreen> Poi ricompila ed installa il nuovo kernel. Quando lo screen-saver viene attivato <tt/kerneld/ eseguirà il comando <tt>/sbin/screen-blanker</tt> (questo può essere uno <sl/script/ di <sl/shell/ che lancia il tuo screen-saver favorito). Quando il kernel vuole ripristinare lo schermo invia un segnale SIGQUIT al processo che sta eseguendo <tt>/sbin/screenblanker</tt>. Lo <sl/script/ di <sl/shell/ deve poterlo catturare e terminare. Ricordati di ripristinare lo schermo alla modalità testo originale! <sect>Problemi comuni e cose di cui non capisci il motivo <label id="CommonProblems"> <sect1>Perché ottengo il messaggio ``Cannot locate module for net-pf-<it/x/'' (Non riesco a trovare il modulo per net-pf-<it/x/) quando lancio ifconfig? Circa alla versione 1.3.80 del kernel, il codice per la gestione delle reti fu cambiato per permettere il caricamento di famiglie di protocolli (per esempio IPX, AX.25 e AppleTalk) come moduli. Ciò causò l'aggiunta di una nuova richiesta di <tt/kerneld/: net-pf-<it/X/, dove <it/X/ è un numero che identifica il protocollo (vedi <tt>/usr/src/linux/include/linux/socket.h</tt> per il significato dei vari numeri). Sfortunatamente ifconfig provoca in modo accidentale questi messaggi, cosicché molte persone ottengono un paio di messaggi di <sl/log/ quando il sistema viene avviato e viene lanciato ifconfig per configurare la periferica <sl/loopback/. I messaggi non indicano nulla di pericoloso e puoi disabilitarli aggiungendo le linee: <tscreen><verb> alias net-pf-3 off # Dimenticati di AX.25 alias net-pf-4 off # Dimenticati di IPX alias net-pf-5 off # Dimenticati di AppleTalk </verb></tscreen> a <tt>/etc/conf.modules</tt>. Ovviamente, se utilizzi IPX come modulo, non devi aggiungere la linea che lo disabiliti. <sect1>Dopo la partenza di <tt/kerneld/ il mio sistema viene messo in ginocchio quando attivo una connessione ppp Ci sono stati un paio di casi di questo problema. Sembra essere dovuto ad una sfortunata interazione fra <tt/kerneld/ e lo <sl/script/ <bf/tkPPP/ che viene usato su alcuni sistemi per impostare e configurare la connessione PPP (lo <sl/script/, apparentemente, si morde la coda mentre esegue ifconfig). Questo richiama <tt/kerneld/ per cercare i moduli net-pf-<it/x/ (vedi sopra), tenendo il sistema in sovraccarico e generando, eventualmente, un sacco si messaggi del tipo «Cannot locate module for net-pf-<it/x/» nel <sl/log/ di sistema. Non si conosce alcun modo per aggirare il problema, se non quello di evitare tkPPP o di cambiarlo usando qualche altro modo per tenere sotto controllo la connessione. <sect1><tt/kerneld/ non carica il mio driver SCSI! Aggiungi una voce per il tuo adattatore SCSI al tuo <tt>/etc/conf.module</tt>. Vai a vedere la descrizione della voce <ref id="scsidevs" name="scsi_hostadapter"> sopra. <sect1>modprobe si lamenta che «gcc2_compiled» non è definito Questo è un errore nelle utility dei moduli che si verifica solo con le binutils 2.6.0.9 e seguenti, e che è anche documentato nelle note per le binutils. Dacci un'occhiata. Oppure procurati un aggiornamento per le utility dei moduli che porgano rimedio, come per esempio modules-2.0.0. <sect1>Il driver della mia scheda sonora non si ricorda delle impostazioni per il volume, etc. Le impostazioni per un modulo sono salvate all'interno del modulo stesso quando viene caricato. Cosí, quando <tt/kerneld/ auto-scarica il modulo, ogni impostazione che hai fatto viene dimenticata e la volta successiva il modulo ritorna alle impostazioni di default. Puoi dire a <tt/kerneld/ di configurare un modulo, eseguendo un programma, dopo che il modulo è stato auto-caricato. Vedere la <ref id="pre_post" name="sezione sopra"> per la voce «post-install». <sect1>Dosemu ha bisogno di alcuni moduli. Come posso fare affinché <tt/kerneld/ li carichi? Non puoi. Nessuna delle versioni di Dosemu (ufficiali o di sviluppo) supporta il caricamento dei moduli di Dosemu attraverso <tt/kerneld/. Però, se stai utilizzando un kernel 2.0.26 o successivi, non hai piú bisogno di alcun modulo speciale Dosemu. Semplicemente aggiornati alla versione 0.66.1. <sect1>Perché ottengo un messaggio ``Ouch, kerneld timed out, message failed'' (Oops, tempo scaduto per kerneld, messaggio fallito)? Quando il kernel invia una richiesta a <tt/kerneld/, si aspetta di ottenere un «ricevuto» entro un secondo. Se <tt/kerneld/ non invia questo riscontro, il messaggio d'errore viene registrato nel <sl/log/ di sistema. La richiesta viene ritrasmessa e dovrebbe arrivare a destinazione. Questo di solito capita su sistemi con un carico elevato (poiché <tt/kerneld/ è un processo eseguito in modalità utente, esso viene <it/schedulato/ come ogni altro processo sul sistema). In momenti di alto carico, può non riuscire ad inviare per tempo il «ricevuto», prima che scada il tempo per kernel. Se questo accade anche quando il carico è scarso, prova a far ripartire <tt/kerneld/. Uccidi il processo <tt/kerneld/ e fallo ripartire ancora con il comando <tt>/usr/sbin/<tt/kerneld/</tt>. Se il problema persiste, dovresti inviare un messaggio con l'errore a <htmlurl url="mailto:linux-kernel@vger.rutgers.edu" name="<linux-kernel@vger.rutgers.edu>">, ma <bf/ti prego/ di assicurarti che la tua versione di kernel e <tt/kerneld/ sia aggiornata prima di spedire messaggi sul problema. <sect1>mount non aspetta che <tt/kerneld/ carichi il modulo per il <sl/ filesystem/ Ci sono stati un certo numero di casi per i quali il comando mount(8) non aspettava che <tt/kerneld/ finisse di caricare il modulo del <sl/filesystem/. lsmod mostrava che <tt/kerneld/ aveva caricato il modulo e, ripetendo il comando mount subito dopo, questo in effetti veniva fatto. Questo sembra fosse dovuto ad un errore nella versione 1.3.9f delle utility per i moduli che affliggeva alcuni utenti Debian (può essere eliminato procurandosi una versione successiva delle utility per i moduli). <sect1><tt/kerneld/ fallisce nel caricare il modulo ncpfs Hai bisogno di compilare le utility per ncpfs con l'opzione -DHAVE_KERNELD. Vedere il Makefile di ncpfs. <sect1><tt/kerneld/ fallisce nel caricare il modulo per smbfs Stai usando un versione delle utility per smbmount troppo vecchia. Procurati l'ultima versione (0.10 o successive) da <url url="ftp://tsx-11.mit.edu/pub/linux/filesystems/smbfs/"> <sect1>Ho compilato tutto come modulo e ora il mio sistema non si avvia piú <sect1><tt/kerneld/ fallisce nel caricare il <sl/ filesystem/ principale Non puoi rendere modulare <bf/tutto/: il kernel deve avere abbastanza driver compilati normalmente affinché sia capace di fare il <sl/mount/ del <sl/filesystem/ principale ed eseguire i programmi necessari ad avviare <tt/kerneld/. Cosí non puoi rendere modulare: <itemize> <item>il driver per l'hard-disk sul quale risiede il <sl/filesystem/ principale; <item>il driver del <sl/filesystem/ stesso; <item>il caricatore del formato binario di init, <tt/kerneld/ e altri programmi. </itemize> In effetti questo non è vero. L'ultimo kernel 1.3.x e tutti i 2.x supportano l'uso di un <sl/ram-disk/ iniziale che viene caricato da LILO o LOADLIN, ed è possibile caricare moduli da questo «disco» molto presto all'interno del processo di avvio. Il procedimento per farlo è descritto nel file Documentation/initrd.txt contenuto con i sorgenti del kernel. <sect1><tt/kerneld/ non viene caricato all'avvio - si lamenta di libgdbm Le versioni piú recenti di <tt/kerneld/ hanno bisogno delle librerie dbm di GNU, le libgdbm.so, per girare. Molte installazione hanno questo file in <tt>/usr/lib</tt>, mentre tu stai probabilmente lanciando <tt/kerneld/ prima che il <sl/filesystem/ sia stato montato. Un sintomo di questo è che <tt/kerneld/ non parte durante l'avvio (dai tuoi <sl/script/ rc), ma va bene se lo lanci manualmente dopo che il sistema è partito. La soluzione consiste nello spostare l'avvio di <tt/kerneld/ dopo che di <tt>/usr</tt> ne sia stato fatto il <sl/mount/ oppure spostare la libreria gdbm sul <sl/filesystem/ principale, per esempio in <tt>/lib</tt>. <sect1>Ottengo un ``Cannot load module <it/xxx/'' (Non posso caricare il modulo <it/xxx/), ma ho appena riconfigurato il kernel senza il supporto per <it/xxx/! L'installazione Slackware (possibilmente altre) crea un file <tt>/etc/rc.d/rc.modules</tt> che opera un esplicito <tt/modprobe/ su una varietà di moduli. Quali moduli esattamente vengano testati dipende dalla configurazione originale del kernel. Hai probabilmente riconfigurato il tuo kernel escludendo uno o piú dei moduli che vengono testati in <tt/rc.modules/, cosí il messaggio/i di errore. Aggiorna il tuo rc.modules «commentando» ogni modulo che non usi piú, o cancella <tt/rc.modules/ completamente e lascia che <tt/kerneld/ carichi i moduli quando ne ha bisogno. <sect1>Ho ricompilato il kernel e i moduli, e continuo ad ottenere messaggi di simboli non risolti all'avvio Probabilmente hai riconfigurato e ricompilato il tuo kernel escludendo alcuni moduli. Hai ancora alcuni vecchi moduli che non utilizzi piú sparsi in giro per il directory <tt>/lib/modules</tt>. La soluzione piú semplice è quella di cancellare la directory <tt>/lib/modules/x.y.z</tt> e dare un altro <tt/make modules_install/ dalla directory dei sorgenti del kernel. Nota che questo problema capita solo quando si riconfigura il kernel senza cambiamenti di versione. Se vedi questo errore quando ti stai aggiornando ad una versione piú nuova, hai un altro tipo di problema. <sect1>Ho installato Linux 2.1 e ora non riesco piú a caricare alcun modulo<label id="2-1-problems"> Linux 2.1 è il kernel attualmente in fase di sviluppo. Come tale ci si può aspettare che le cose cambino da un momento all'altro. Una delle cose che è cambiata in maniera significativa è il modo con il quale vengono trattati i moduli e dove il kernel e i moduli vengono caricati in memoria. Inoltre ora è Richard Henderson che si occupa dello sviluppo dei moduli del kernel. In breve, se vuoi utilizzare i moduli con un kernel 2.1, devi: <itemize> <item>leggere il file Documentation/Changes e vedere quali pacchetti hanno bisogno di essere aggiornati sul tuo sistema <item>usare l'ultimo pacchetto modutils, disponibile da <url url="ftp://ftp.redhat.com/pub/alphabits/"> o dal sito <sl/mirror/ presso <url url="ftp://tsx-11.mit.edu/pub/linux/packages/alphabits/"> </itemize> Ti raccomando di utilizzare almeno un kernel 2.1.29 se vuoi usare i moduli con un kernel 2.1. <sect1>E a proposito del collegamento alla rete su richiesta? <tt/kerneld/ originariamente aveva qualche supporto per stabilire una connessione di rete in <sl/dial-up/ su richiesta; provando a spedire pacchetti ad una rete senza essere connessi, faceva lanciare a <tt/kerneld/ lo <sl/script/ <tt>/sbin/request_route</tt> per istituire la connessione PPP o SLIP. Questo si rivelò essere una cattiva idea. Alan Cox, uno dei famosi nel <sl/networking/ di Linux, scrisse sulla <sl/mailing list/ linux-kernel: <quote> Il materiale su request_route è obsoleto, inefficiente e inutile [...]. Inoltre è stato rimosso dalla struttura 2.1.x. </quote> Invece di usare lo <sl/script/ request_route e <tt/kerneld/, voglio vivamente consigliarti di installare il pacchetto <url url="http://www.dna.lth.se/~erics/diald.html" name="diald"> di Eric Schenk. <sect>Messaggio di copyright<label id="A9"> This document is Copyright (c) Henrik Storner, 1996, 1997. Unless otherwise stated, Linux HOWTO documents are copyrighted by their respective authors. Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions. All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below. In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs. <quote> <em/L'unica licenza valida è quella originale in lingua inglese. Di seguito ne trovate una traduzione abbastanza fedele che però non ha alcun valore./ </quote> Questo HOWTO è di Henrik Storner (1996-97) ed è distribuito, come gli altri HOWTO di Linux, sotto i termini descritti qui di seguito. Finché non diversamente asserito, i documenti HOWTO di Linux sono proprietà dei rispettivi autori. I documenti degli HOWTO di Linux possono essere riprodotti e distribuiti in tutto o in parte, con ogni mezzo fisico o elettronico, finché questo avviso di copyright è mantenuto su tutte le copie. La distribuzione commerciale è permessa e incoraggiata; comunque all'autore piacerebbe essere avvisato di ogni distribuzione di questo tipo. Ogni traduzione, lavoro derivato o comprendente ogni documento degli HOWTO di Linux deve essere coperto sotto questo avviso di copyright. Cioé non potete produrre un lavoro derivato da un HOWTO e imporre restrizioni aggiuntive sulla sua distribuzione. Eccezioni a queste regole possono essere garantite sotto certe condizioni; contattate il coordinatore degli HOWTO di Linux all'indirizzo indicato sotto. In breve vogliamo promuovere la distribuzione di queste informazioni attraverso quanti piú canali possibile. Ciò nonostante vogliamo che rimanga il copyright sui documenti HOWTO e vorremmo venir avvisati di ogni progetto per la ridistribuzione degli HOWTO. Se avete domande contattate Tim Bynum, il coordinatore degli HOWTO di Linux, all'indirizzo di posta elettronica <htmlurl url="mailto:linux-howto@sunsite.unc.edu" name="<linux-howto@sunsite.unc.edu>">. </article>