Linux kerneld mini-HOWTO

1.1. Ringraziamenti

Questo documento è basato su un HTML originale versione 1.7 datata 19 luglio 1997 di Henrik Storner <storner@osiris.ping.dk> ed è stata rivista e tradotta per il DocBook DTD da Gary Lawrence Murphy <garym@teledyn.com> 20 maggio 2000.

Le persone seguenti hanno contribuito in qualche modo a questo mini-HOWTO:

• Bjorn Ekwall bj0rn@blox.se

• Ben Galliart bgallia@luc.edu

• Cedric Tefft cedric@earthling.net

• Brian Miller bmiller@netspace.net.au

• James C. Tsiao jtsiao@madoka.jpl.nasa.gov

Se si dovessero trovare degli errori in questo documento, si prega di spedire una e-mail a <kerneld-howto@linuxdoc.org>. Commenti, incoraggiamenti e suggerimenti sono benvenuti e apprezzati e aiutano ad assicurare che questa guida rimanga aggiornata ed accurata.

2.1. Perché avrei bisogno di usarlo?

Ci sono alcune buone ragioni per usare kerneld. Quelle che menzionerò sono le mie, gli altri potrebbero volerlo usare per altri motivi.

• Se c'è la necessità di compilare dei kernel per svariati sistemi che si distinguono di poco, come ad esempio differenti tipi di schede di rete, è possibile preparare un singolo kernel e alcuni moduli invece di essere costretti a compilare un kernel per ogni sistema.

• 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 kerneld.

• Limita l'utilizzo di memoria da parte del kernel, cioè si possiede più memoria disponibile per le applicazioni. La memoria usata dal kernel non è mai trasferita alla memoria di swap, così, se ci sono 100kB di driver inutilizzati compilati nel kernel, questi sono semplicemente RAM sprecata.

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

• Le persone che curano le distribuzioni di Linux non devono compilare 284 differenti immagini di boot: ogni utente carica i driver di cui ha bisogno per il suo hardware. Distribuzioni Linux più moderne rileveranno l'hardware in uso e caricheranno solamente i moduli effettivamente necessari.

Certamente ci sono anche ragioni per le quali si potrebbe non volerlo usare (ad esempio quando si preferisce un unico file d'immagine per il kernel con tutti i driver compilati staticamente). In tal caso state leggendo il documento sbagliato.

2.2. Dove posso prelevare i componenti necessari?

Il supporto nel kernel di Linux fu introdotto con Linux 1.3.57. Se si possiede una versione di kernel precedente, sarà necessario aggiornarla se si desidera il supporto per kerneld. Tutti i maggiori siti ftp di Linux contengono i sorgenti del kernel inclusi:

• Kernel.Org Archive

• Metalab Linux Archive

• TSX-11 presso il MIT

Il demone a livello utente è incluso nel pacchetto modules. Questi sono normalmente disponibili dallo stesso sito in cui sono stati trovati i sorgenti del kernel.

se si vuole provare a caricare i moduli con gli ultimi kernel in fase di sviluppo, è necessario procurarsi il più recente pacchetto modutils e non modules. Controllare sempre il file Documentation/Changes nei sorgenti del kernel per il numero di versione minimo richiesto per la propria immagine del kernel. Si veda anche la sezione sui problemi comuni per i problemi che si possono avere con i moduli ed il kernel 2.1.

3.1. Proviamo kerneld

Ora si faccia il reboot con il nuovo kernel. Quando il sistema è di nuovo pronto, si impartisca un ps ax con il quale si dovrebbe vedere una linea per kerneld:

    PID TTY STAT  TIME COMMAND
     59  ?  S     0:01 /sbin/kerneld

Una delle cose carine con kerneld è che, una volta che il kernel e il demone sono stati installati, poche impostazioni sono ancora necessarie. Per un inizio si provi ad usare uno dei driver compilati come modulo (in generale tutto funziona senza ulteriori configurazioni). Personalmente ho compilato il driver per il floppy come modulo, così posso mettere un dischetto DOS nel drive e digitare

  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

Il driver del floppy funziona! Viene caricato automaticamente da kerneld quando provo ad usare il disco floppy.

Per vedere, invece, che il modulo del floppy è effettivamente caricato, è possibile lanciare /sbin/lsmod che lista tutti i moduli attualmente caricati:

  osiris:~ $ /sbin/lsmod
  Module:        #pages:  Used by:
  floppy            11    0 (autoclean)

"(autoclean)" sta ad indicare che il modulo verrà automaticamente rimosso da kerneld dopo che 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 proprie applicazioni!

4.1. Periferiche a blocchi

Se viene eseguito /sbin/modprobe -c, si otterrà una lista di moduli conosciuti da kerneld e di richieste alle quali questi corrispondono. Per esempio, la richiesta che termina con il caricamento del driver per il floppy è per la periferica a blocchi con major number pari a 2:

  osiris:~ $ /sbin/modprobe -c | grep floppy
  alias block-major-2 floppy

Perché block-major-2? Perché le periferiche floppy /dev/fd* usano dispositivi con major 2 e sono periferiche a blocchi:

  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

4.2. Periferiche a caratteri

Le periferiche a caratteri sono trattate in modo analogo. Per esempio il driver per l'unità a nastro connessa come floppy ha un major di 27:

  osiris:~ $ ls -lL /dev/ftape
  crw-rw----   1 root     disk      27,   0 Jul 18  1994 /dev/ftape

Però kerneld non conosce nulla per default del driver per l'unità a nastro. Infatti non è presente nella lista ottenuta con /sbin/modprobe -c. Così per impostare kerneld affinché carichi il driver per l'unità a nastro, si deve aggiungere una linea al file di configurazione di kerneld, /etc/conf.modules:

  alias char-major-27 ftape

4.3. Periferiche di rete

È possibile anche usare il nome della periferica al posto di impostazioni come char-major-xxx o block-major-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

  alias eth0 ne

Se si necessita di passare alcune opzioni al driver, per esempio per informare il modulo su quale IRQ la scheda di rete stia usando, aggiungere una linea "options":

  options ne irq=5

Questo farà in modo che kerneld carichi il driver NE2000 con il comando:

  /sbin/modprobe ne irq=5

Ovviamente le opzioni effettivamente disponibili sono specifiche al modulo che si carica.

4.4. Formati binari

I formati binari sono trattati in modo simile. Ogni volta che si prova a lanciare un programma che kerneld non sa come caricare, kerneld riceve una richiesta per binfmt-xxx, dove xxx è un numero determinato dai primi byte dell'eseguibile. Così la configurazione di kerneld per supportare il modulo binfmt_aout per gli eseguibili ZMAGIC (a.out) è:

  alias binfmt-267 binfmt_aout

poiché il magic number per i file ZMAGIC è 267. Se si controlla il file /etc/magic si troverà 0413. Si tenga presente che /etc/magic usa numeri in formato ottale, mentre kerneld usa il formato decimale e il numero 413 in base ottale corrisponde al numero decimale 267.

In realtà ci sono tre varianti leggermente diverse per gli eseguibili a.out (NMAGIC, QMAGIC e ZMAGIC), così per un pieno supporto del modulo binfmt_aout abbiamo bisogno di:

  alias binfmt-264 binfmt_aout  # pure executable (NMAGIC)
  alias binfmt-267 binfmt_aout  # demand-paged executable (ZMAGIC)
  alias binfmt-204 binfmt_aout  # demand-paged executable (QMAGIC)

I formati binari a.out, Java e iBCS sono riconosciuti automaticamente da kerneld senza alcuna configurazione.

4.5. Discipline di linea (slip, cslip e ppp)

Le discipline di linea sono richieste con tty-ldisc-x, dove x assume solitamente i valori 1 (per SLIP) o 3 (per PPP). Entrambi sono riconosciuti da kerneld automaticamente.

A proposito di ppp, se si desidera che kerneld carichi il modulo bsd_comp per la compressione dei dati per ppp, allora è necessario aggiungere le due linee seguenti al proprio /etc/conf.modules:

  alias tty-ldisc-3 bsd_comp
  alias ppp0 bsd_comp

4.6. Famiglie di protocolli di rete (IPX, AppleTalk, AX.25)

Anche alcuni protocolli di rete possono essere caricati come moduli. Il kernel domanda a kerneld una famiglia di protocolli (per esempio IPX) con una richiesta del tipo net-pf-X, dove 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 include/linux/socket.h). Così per caricare automaticamente il modulo IPX è necessario aggiungere al file /etc/conf.modules una linea come questa:

  alias net-pf-4 ipx

Si veda anche la sezione riguardante i problemi comuni per informazioni su come evitare alcuni noiosi messaggi all'avvio relativi a famiglie di protocolli indefiniti.

4.7. I file system

Le richieste di kerneld per i filesystem sono semplicemente i nomi del tipo di filesystem. Un comune uso potrebbe essere quello di caricare il modulo isofs per il filesystem del CD-ROM, cioè per il filesystem di tipo iso9660:

  alias iso9660 isofs

5.1. char-major-10 : mouse, watchdog e casualità

Le periferiche hardware sono solitamente identificate con il loro major number, così per l'unità a nastro si ha un char-major-27. Ciò nonostante, se si scorrono le voci presenti in /dev che contengono un char-major-10, si vedrà che queste formano un bel gruppo di periferiche molto diverse fra loro:

• mouse di vario genere (bus mouse, mouse PS/2),

• periferiche watchdog,

• il dispositivo random del kernel,

• interfaccia APM (Advanced Power Management).

Queste periferiche sono controllate da altrettanti moduli, non da uno solo. Perciò la configurazione di kerneld per queste periferiche eterogenee fa uso del major number e del minor number:

        alias char-major-10-1 psaux     # For PS/2 mouse
        alias char-major-10-130 wdt     # For WDT watchdog

Si necessita di una versione del kernel 1.3.82 o superiore per poter utilizzare questa caratteristica; le versioni precedenti non passano il minor number a kerneld, impedendogli di capire quale modulo di periferica caricare.

5.2. Caricamento di driver SCSI: la voce scsi_hostadapter

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 si utilizza (per esempio un hard-disk, un CD-ROM o un'unità a nastro). Tutti possono essere caricati come moduli. Perciò, quando desidera accedere, per esempio, al lettore di CD-ROM connesso alla scheda Adaptec, il kernel e kerneld sanno solo che c'è bisogno di caricare il modulo 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 si può aggiungere una voce per il driver SCSI al proprio /etc/conf.modules che dica a kerneld quale dei possibili moduli per controller SCSI deve caricare:

        alias scd0 sr_mod               # sr_mod for SCSI CD-ROM's ...
        alias scsi_hostadapter aha1542  # ... need the Adaptec driver

Questo funziona solo con versioni del kernel 1.3.82 o superiori.

Il metodo va bene se si possiede un solo controller SCSI. Se ce ne sono più d'uno, le cose diventano un po' più difficili.

In generale è possibile fare in modo che kerneld carichi un driver per un adattatore SCSI se un driver per un altro adattatore SCSI è già installato. Si è costretti a compilare entrambi i driver direttamente nel kernel (non come moduli) o caricare i moduli manualmente.

Tuttavia un modo per caricare più driver SCSI esiste. James Tsiao ha avuto questa idea: È facile fare in modo che kerneld carichi il secondo driver scsi: basta impostare le dipendenze in modules.dep a mano. Serve solo una voce come: /lib/modules/2.0.30/scsi/st.o: /lib/modules/2.0.30/scsi/aha1542.o per far caricare a 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 le periferiche scsi generiche. L'altra faccia della medaglia sta nel fatto che depmod -a non può rilevare automaticamente queste dipendenze, così l'utente ha bisogno di aggiungerle manualmente e non può lanciare depmod -a all'avvio. Ma, una volta che tutto è configurato, kerneld caricherà in automatico l'aha1542.o senza problemi.

Si faccia presente che questa tecnica funziona solo se si possiedono 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).

5.3. Quando caricare un modulo non è sufficiente: la voce post-install entry

Qualche volta caricare solo il modulo non è abbastanza per far funzionare le cose. Per esempio, se la seconda scheda sonora è stata compilata 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 Ben Galliart (<bgallia@luc.edu>):

La soluzione definitiva ha richiesto l'installazione del pacchetto setmix e l'aggiunta delle seguenti linee al mio /etc/conf.modules:

post-install sound /usr/local/bin/setmix -f /etc/volume.conf

Questa linea fa in modo che 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 /usr/local/bin/setmix -f /etc/volume.conf.

Ciò può essere utile anche per altri moduli, per esempio il modulo lp può essere configurato con il programma tunelp aggiungendo:

        post-install lp tunelp options

Affinché kerneld recepisca queste opzioni, si necessità di una versione di kerneld 1.3.69f o superiore.

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 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 release futura di kerneld). L'intera struttura delle impostazioni per un modulo sta subendo alcuni cambiamenti in questo momento e potrebbe essere diversa sul proprio sistema.