<!DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook V3.1//EN"[
]>
<article class="journalarticle"
         status="DRAFT"
         id="kerneld" lang="it"
         xreflabel="kerneld mini-HOWTO"
         os="linux"
         revision="$Id: kerneld.sgml,v 1.2 2000/12/28 10:20:58 lolo Exp lolo $"
         vendor="Linux Documentation Project">
  <artheader>
    <title>Linux kerneld mini-HOWTO</title>
    <authorgroup>
    <author>
      <firstname>Henrik</firstname>
      <surname>Storner</surname>
      <affiliation>
        <address><email>kerneld-howto@linuxdoc.org</email></address>
      </affiliation>
    </author>
    </authorgroup>

    <revhistory>
      <revision>
         <revnumber>v2.0</revnumber>
         <date>22 Maggio 2000</date>
          <revremark>
            conversione da HTML a DocBook SGML.
         </revremark>
      </revision>
    </revhistory>

    <copyright>
      <year>2000</year>
      <holder role="mailto:kerneld-howto@linuxdoc.org">Linux Documentation
      Project</holder>
    </copyright>
    <legalnotice>
      <title>Copyright</title>
      <para>This document is Copyright by Henrik Storner, 1996, 1997.</para>

      <para>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.</para>

      <para>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.</para>

      <para>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.</para>

      <para>If you have questions, please contact the Linux HOWTO
      coordinator, at linux-howto@sunsite.unc.edu via email.</para>
    </legalnotice>

    <legalnotice>
      <para><emphasis>L'unica licenza valida &egrave; quella originale in
      lingua inglese. Di seguito ne trovate una traduzione abbastanza
      fedele che per&ograve; non ha alcun valore legale.</emphasis></para>

      <para>Questo HOWTO &egrave; di Henrik Storner (1996-97) ed &egrave;
      distribuito, come gli altri HOWTO di Linux, sotto i termini
      descritti qui di seguito.</para>

      <para>Se non diversamente specificato, i documenti HOWTO di
      Linux sono propriet&agrave; 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, purch&eacute; questo
      avviso di copyright sia mantenuto su tutte le copie. La
      distribuzione commerciale &egrave; permessa e incoraggiata; comunque
      all'autore piacerebbe essere avvisato di ogni distribuzione di
      questo tipo.</para>

      <para>Ogni traduzione, lavoro derivato o comprendente ogni
      documento degli HOWTO di Linux deve essere coperto sotto questo
      avviso di copyright. Cio&egrave; 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.</para>

      <para>In breve vogliamo promuovere la distribuzione di queste
      informazioni attraverso quanti pi&ugrave; canali possibile. Ci&ograve;
      nonostante vogliamo che rimanga il copyright sui documenti HOWTO
      e vorremmo venir avvisati di ogni progetto per la
      ridistribuzione degli HOWTO.</para>

      <para>Se avete domande contattate il coordinatore degli HOWTO di
      Linux, all'indirizzo linux-howto@sunsite.unc.edu via
      email.</para>
    </legalnotice>

  </artheader>

  <sect1><title>A proposito del kerneld mini-HOWTO</title>

      <para>Questo documento spiega come installare e utilizzare il
      caricatore automatico di moduli per il kernel
      <quote>kerneld</quote>. L'ultima versione originale rilasciata
      di questo documento pu&ograve; essere trovata presso il <ulink
      url="http://tldp.org">Linux Documentation
      Project</ulink>.</para>
      <para>[NdT: la traduzione italiana è reperibile presso il sito
      dell'Italian Linux Documentation Project (<ulink
      url="http://it.tldp.org">http://it.tldp.org</ulink>). Traduzione a cura
      di Lorenzo Cappelletti (lorenzo.cappelletti(at)email.it) e revisione a
      cura di Luca Bruno (luca(at)unofree.it)]</para>

   <sect2 id="credits"><title>Ringraziamenti</title>

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

      <para>Le persone seguenti hanno contribuito in qualche modo a
      questo mini-HOWTO:</para>

      <itemizedlist>
        <LISTITEM>
		<PARA>Bjorn Ekwall bj0rn@blox.se</PARA>
	</LISTITEM>
        <LISTITEM>
		<PARA>Ben Galliart bgallia@luc.edu</PARA>
	</LISTITEM>
        <LISTITEM>
		<PARA>Cedric Tefft cedric@earthling.net</PARA>
	</LISTITEM>
	<LISTITEM>
		<PARA>Brian Miller bmiller@netspace.net.au</PARA>
	</LISTITEM>
        <LISTITEM>
		<PARA>James C. Tsiao jtsiao@madoka.jpl.nasa.gov</PARA>
	</LISTITEM>
      </itemizedlist>

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

    </sect2>
  </sect1>
  <sect1 id="introduction"><title>Cos'&egrave; kerneld?</title>

      <para>kerneld &egrave; una caratteristica introdotta durante lo
      sviluppo dei kernel 1.3 da Bjorn Ekwall. Essa permette ai
      moduli del kernel come driver di periferica, driver di rete e
      filesystem di venir caricati all'occorrenza automaticamente
      invece di doverlo fare manualmente con
      <command>modprobe</command> o <command>insmod</command>.</para>

      <para>E per motivi ancor pi&ugrave; divertenti, nonostante questi non
      siano (ancora?) integrati con il kernel standard:</para>

      <itemizedlist>
      <listitem><para>pu&ograve; essere impostato per lanciare un programma
      utente, invece del solito schermo nero, permettendo cos&igrave; di
      usare qualsiasi programma come uno
      screen-saver;</para></listitem>

      <listitem><para>in modo analogo al supporto dell'oscuramento
      dello schermo, &egrave; anche possibile cambiare il &laquo;beep&raquo; di console
      in qualche cosa di completamente differente.</para></listitem>
    </itemizedlist>

    <para>kerneld consiste di due componenti:</para>

    <itemizedlist>
      <listitem><para>un supporto nel kernel di Linux che permette di
      inviare delle richieste ad un demone, affinch&eacute; sappia che un
      modulo &egrave; necessario per una certa operazione;</para></listitem>
      <listitem><para>un demone a livello utente che capisca quali
      moduli devono essere caricati per soddisfare le richieste del
      kernel.</para></listitem>
    </itemizedlist>

    <para>Entrambe le parti dovranno essere operative per far
    funzionare il supporto kerneld. Non &egrave; sufficiente che ne sia
    configurata una sola.</para>


    <sect2 id="whi"><title>Perch&eacute; avrei bisogno di usarlo?</title>

      <para>Ci sono alcune buone ragioni per usare kerneld. Quelle
      che menzioner&ograve; sono le mie, gli altri potrebbero volerlo usare
      per altri motivi.</para>

      <itemizedlist>
        <LISTITEM><PARA>Se c'&egrave; la necessit&agrave; di compilare dei kernel
        per svariati sistemi che si distinguono di poco, come ad esempio differenti
	tipi di schede di rete, &egrave; possibile preparare un singolo kernel e
	alcuni moduli invece di essere costretti a compilare un kernel per ogni 
	sistema.</PARA></LISTITEM>

        <LISTITEM><PARA>I moduli sono pi&ugrave; facili da provare per gli
        sviluppatori. Non c'&egrave; bisogno di ravviare il sistema per
        caricare e scaricare i driver. Questo vale per tutti i
        moduli, non solo per quelli caricati da
        kerneld.</PARA></LISTITEM>

        <LISTITEM><PARA >Limita l'utilizzo di memoria da parte del
        kernel, cio&egrave; si possiede pi&ugrave; memoria disponibile per le
        applicazioni. La memoria usata dal kernel non &egrave;
        <emphasis>mai</emphasis> trasferita alla memoria di swap,
        cos&igrave;, se ci sono 100kB di driver inutilizzati compilati nel
        kernel, questi sono semplicemente RAM
        sprecata.</PARA></LISTITEM>

        <LISTITEM><PARA>Alcune delle cose che uso (il driver per
        l'unit&agrave; 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.</PARA></LISTITEM>


        <LISTITEM><PARA>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&ugrave; moderne rileveranno
        l'hardware in uso e caricheranno solamente i moduli
        effettivamente necessari.</PARA></LISTITEM>
      </itemizedlist>

      <para>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.</para>

    </sect2>
    <sect2 id="where"><title>Dove posso prelevare i componenti
    necessari?</title>

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

      <itemizedlist>
        <listitem>
          <para><ulink
          url="ftp://ftp.kernel.org/pub/linux/kernel/">Kernel.Org
          Archive</ulink></para>
        </listitem>
        <listitem>
          <para><ulink
          url="ftp://metalab.unc.edu/pub/Linux/kernel/">Metalab Linux
          Archive</ulink></para>
        </listitem>
        <listitem>
          <para><ulink
          url="ftp://tsx-11.mit.edu/pub/linux/sources/system/">TSX-11
          presso il MIT</ulink></para>
        </listitem>
      </itemizedlist>

      <para>Il demone a livello utente &egrave; incluso nel pacchetto
      <productname>modules</productname>. Questi sono normalmente
      disponibili dallo stesso sito in cui sono stati trovati i
      sorgenti del kernel.</para>

      <note>
      <para>se si vuole provare a caricare i moduli con gli ultimi
      kernel in fase di <emphasis>sviluppo</emphasis>, &egrave; necessario
      procurarsi il pi&ugrave; recente pacchetto <productname>modutils</productname> e
      non <productname>modules</productname>. Controllare sempre il
      file <filename>Documentation/Changes</filename> nei sorgenti del
      kernel per il numero di versione minimo richiesto per la propria
      immagine del kernel. Si veda anche la sezione sui <xref
      linkend="kernel2-1-problems"> per i problemi che si possono
      avere con i moduli ed il kernel 2.1.</para></note>

    </sect2>
    </sect1>

    <sect1 id="setup"><title>Come impostare il tutto?</title>

      <para>Primo procurarsi i componenti necessari: un kernel adatto
      e l'ultimo pacchetto di <productname>modules</productname>.
      Successivamente si devono installare le utilit&agrave; per i moduli come
      indicato nelle istruzioni incluse nel pacchetto. Molto
      semplice: decomprimere i sorgenti e lanciare <command>make
      install</command>. Questo compila e installa in
      <filename>/sbin</filename> i seguenti programmi:
      <command>genksysm</command>, <command>insmod</command>,
      <command>lsmod</command>, <command>modprobe</command>,
      <command>depmod</command> e <command>kerneld</command>. Si
      raccomanda di aggiungere le seguenti linee ai propri script di
      avvio che effettuano alcune impostazioni necessarie ogni volta
      che Linux viene avviato. Aggiungere le seguenti linee al
      proprio file <filename>/etc/rc.d/rc.S</filename> (se si utilizza
      Slackware) o a <filename>/etc/rc.d/rc.sysinit</filename> (se si
      utilizza SysVinit, cio&egrave; Debian, Corel, RedHat, Mandrake o
      Caldera):</para>


<programlisting>
# 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/kerneld ]
        then
                /sbin/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
</programlisting>

      <para>Questi comandi potrebbero essere gi&agrave; installati nel
      proprio script di inizializzazione SysV. La prima parte lancia
      kerneld. La seconda parte chiama <command>depmod -a</command>
      all'avvio per costruire una lista di moduli disponibili e
      analizzare le loro inter-dipendenze. La mappa di depmod quindi
      dice a kerneld se, per un modulo che sta per essere caricato, &egrave;
      necessario caricarne un altro prima.</para>

      <note>
        <para>Nelle recenti versioni di kerneld c'&egrave; la possibilit&agrave; di
        fare il link verso le librerie GNU dbm,
        <productname>libgdbm</productname>. Se si abilita questa
        opzione quando si compilano le utilit&agrave; per i moduli,
        <emphasis>kerneld non partir&agrave; se libgdbm non &egrave;
        disponibile</emphasis>, caso che potrebbe accadere se si
        possiede <filename>/usr</filename> su una partizione separata
        e si fa partire kerneld prima che <filename>/usr</filename>
        sia stata montata. La soluzione consigliata &egrave; di spostare
        <filename>libgdbm</filename> da <filename>/usr/lib</filename>
        a <filename>/lib</filename> o linkarla staticamente a
        kerneld.</para></note>

      <para>Successivamente decomprimere i sorgenti del kernel,
      configurarlo e compilarne uno che sia soddisfacente. Se questa
      operazione non &egrave; mai stata fatta prima, &egrave; 
      necessario leggere attentamente il file README che si trova al primo livello
      dei sorgenti di Linux. Quando si lancia <emphasis>make
      config</emphasis> per configurare il kernel, si presti
      attenzione ad alcune domande che appaiono verso l'inizio:</para>

<screen>
  Enable loadable module support (CONFIG_MODULES) [Y/n/?] Y
</screen

      <para>Si rende necessario selezionare il supporto per i moduli
      caricabili altrimenti non ci saranno moduli per kerneld da
      caricare! Rispondere con Yes.</para>

<screen>
  Kernel daemon support (CONFIG_KERNELD) [Y/n/?] Y
</screen>

      <para>Anche questo, ovviamente, &egrave; necessario. A questo punto
      molte delle cose nel kernel possono essere compilate come
      moduli. Si vedranno domande come:</para>

<screen>
  Normal floppy disk support (CONFIG_BLK_DEV_FD) [M/n/y/?]
</screen>

     <para>dove si pu&ograve; rispondere con una <keysym>M</keysym> che sta per
     <quote>Modulo</quote>. Generalmente solo i driver necessari per
     far partire il sistema dovrebbero essere compilati nel kernel;
     gli altri possono essere compilati come moduli.</para>

     <caution>
       <title>Driver essenziali</title> <para>I driver essenziali
       all'avvio del sistema devono essere compilati nel cuore del
       kernel e non possono venir caricati come moduli. Tipicamente
       questi includeranno i driver per l'hard-disk e il driver per il
       filesystem principale. Se si possiede una macchina con pi&ugrave;
       sistemi operativi e ci si basa su file che si trovano su una
       partizione estranea, &egrave; necessario compilare anche il supporto
       per quel tipo di filesystem nel cuore del kernel.</para>
     </caution>

     <para>Una volta finito con <command>make config</command>,
     compilare ed installare il nuovo kernel e i moduli con
     <command>make dep clean bzlilo modules
     modules_install</command>.</para>

     <para>Fiuuu!!!</para>

     <tip>
       <title>Compilare un'immagine del kernel</title> <para>Il
       comando <command>make zImage</command> mette la nuova immagine
       del kernel nel file
       <filename>/arch/i386/boot/zImage</filename>. Sar&agrave; quindi
       necessario copiarla dove risiede la propria immagine di boot e
       installarla manualmente con LILO.</para>

       <para>Per maggiori informazioni su come configurare, compilare
       e installare il proprio kernel, controllare il Kernel-HOWTO postato
       regolarmente in <filename>comp.os.linux.answers</filename> e
       disponibile sul <ulink url="http://www.linuxdoc.org">Linux
       Documentation Project</ulink> e relativi mirror.</para></tip>


    <sect2 id="testing"><title>Proviamo kerneld</title>

    <para>Ora si faccia il reboot con il nuovo kernel. Quando il
    sistema &egrave; di nuovo pronto, si impartisca un <command>ps
    ax</command> con il quale si dovrebbe vedere una linea per
    kerneld:</para>

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

    <para>Una delle cose carine con kerneld &egrave; 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&igrave; posso mettere un dischetto DOS nel drive
    e digitare</para>

<screen>
  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
</screen>

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

      <para>Per vedere, invece, che il modulo del floppy &egrave;
      effettivamente caricato, &egrave; possibile lanciare
      <command>/sbin/lsmod</command> che lista tutti i moduli
      attualmente caricati:</para>

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

      <para><quote>(autoclean)</quote> sta ad indicare che il modulo
      verr&agrave; automaticamente rimosso da kerneld dopo che non viene
      usato per pi&ugrave; di un minuto. Cos&igrave; le 11 pagine di memoria (=
      44kB, una pagina &egrave; 4kB) verranno utilizzate solo quando accedo
      al drive del floppy (se non uso il floppy per pi&ugrave; di un minuto,
      verranno liberate). Alquanto carino, se sei a corto di memoria
      per le proprie applicazioni!</para>

    </sect2>
    </sect1>


    <sect1 id="configuration"><title>Come fa kerneld a sapere
    quale modulo caricare?</title>

      <para>Nonostante kerneld venga fornito con informazioni gi&agrave;
      pronte sui tipi pi&ugrave; comuni di moduli, ci sono situazioni in cui
      non sapr&agrave; come trattare una richiesta del kernel. Questo accade
      per moduli tipo il driver per il CD-ROM o i driver di rete, dove
      c'&egrave; pi&ugrave; di un possibile modulo da poter caricare.</para>

      <para>Le richieste che il demone kerneld riceve dal kernel
      possono appartenere ad uno dei seguenti tipi:</para>

      <itemizedlist>
        <LISTITEM><PARA>driver di periferica a
        blocchi</PARA></LISTITEM>

        <LISTITEM><PARA>driver di periferica a
        caratteri</PARA></LISTITEM>

        <LISTITEM><PARA>formato binario</PARA></LISTITEM>

        <LISTITEM><PARA>discipline di linea tty</PARA></LISTITEM>

        <LISTITEM><PARA>filesystem</PARA></LISTITEM>

        <LISTITEM><PARA>periferica di rete</PARA></LISTITEM>

        <LISTITEM><PARA>servizio di rete (per esempio
        rarp)</PARA></LISTITEM>

        <LISTITEM><PARA>protocollo di rete (per esempio
        IPX)</PARA></LISTITEM>
      </itemizedlist>

      <para>Kerneld determina quale modulo dobba essere caricato
      cercando nel file di configurazione
      <filename>/etc/conf.modules</filename><footnote> <para>Alcune
      distribuzioni chimano questo file
      <filename>modules.conf</filename></para> </footnote>. Ci sono
      due tipi di voci possibili in questo file: path (dove si trovano
      i file dei moduli) e alias (quale modulo dovrebbe essere
      caricato per un dato servizio). Se non si possiede gi&agrave; questo
      file, &egrave; possibile crearlo con il comando:

<screen>
  /sbin/modprobe -c | grep -v '^path' /etc/conf.modules
</screen>

      <para>Se si deisdera aggiungere un'altra direttiva &laquo;path&raquo; ai
      percorsi di default, <emphasis>si deve anche includere tutti gli
      altri percorsi di &laquo;default&raquo;</emphasis> in quanto una direttiva
      &laquo;path&raquo; in <filename>/etc/conf.modules</filename>
      <emphasis>rimpiazzer&agrave;</emphasis> tutti quelli che modprobe
      conosce per default!</para>

      <para>Normalmente non si avr&agrave; bisogno di aggiungere alcun
      percorso, in quanto l'insieme di quelli precompilati dovrebbe
      essere sufficiente per tutte le configurazioni &laquo;normali&raquo; (ed
      altre ancora...). Promesso!</para>

      <para>Diversamente, se si desidera aggiungere un &laquo;alias&raquo; o una
      direttiva &laquo;option&raquo;, le nuove voci in
      <filename>/etc/conf.modules</filename> verranno
      <emphasis>aggiunte</emphasis> a quelle che modprobe gi&agrave; conosce.
      Se si deve <emphasis>ridefinire</emphasis> un &laquo;alias&raquo; o
      &laquo;options&raquo;, le nuove voci in
      <filename>/etc/conf.modules</filename> sovrascriveranno quelle
      precompilate.</para>


      <sect2 id="blockdev"><title>Periferiche a blocchi</title>

      <para>Se viene eseguito <command>/sbin/modprobe -c</command>, si
      otterr&agrave; 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 &egrave; per la
      periferica a blocchi con major number pari a 2:</para>

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

      <para>Perch&eacute; <filename>block-major-2</filename>?  Perch&eacute; le
      periferiche floppy <filename>/dev/fd*</filename> usano
      dispositivi con major 2 e sono periferiche a blocchi:</para>

<screen>
  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
</screen>

      </sect2>

      <sect2 id="chardev"><title>Periferiche a caratteri</title>

      <para>Le periferiche a caratteri sono trattate in modo analogo.
      Per esempio il driver per l'unit&agrave; a nastro connessa come floppy
      ha un major di 27:</para>

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

      <para>Per&ograve; kerneld non conosce nulla per default del driver per
      l'unit&agrave; a nastro. Infatti non &egrave; presente nella lista ottenuta
      con <command>/sbin/modprobe -c</command>. Cos&igrave; per impostare
      kerneld affinch&eacute; carichi il driver per l'unit&agrave; a nastro, si deve
      aggiungere una linea al file di configurazione di kerneld,
      <filename>/etc/conf.modules</filename>:</para>

<screen>
  alias char-major-27 ftape
</screen>

      </sect2>

      <sect2 id="eth0"><title>Periferiche di rete</title>

      <para>&Egrave; possibile anche usare il nome della periferica al posto
      di impostazioni come <literal>char-major-xxx</literal> o
      <literal>block-major-yyy</literal>. Questo &egrave; particolarmente
      utile per i driver di rete. Per esempio un driver per una scheda
      di rete tipo ne2000 abilitata come eth0 verrebbe caricato
      con</para>

<screen>
  alias eth0 ne
</screen>

      <para>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 <quote>options</quote>:</para>

<screen>
  options ne irq=5
</screen>

      <para>Questo far&agrave; in modo che kerneld carichi il driver NE2000
      con il comando:</para>

<screen>
  /sbin/modprobe ne irq=5
</screen>

      <para>Ovviamente le opzioni effettivamente disponibili sono
      specifiche al modulo che si carica.</para>

      </sect2>

      <sect2 id="binfmt"><title>Formati binari</title>

      <para>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
      <literal>binfmt-</literal><varname>xxx</varname>, dove
      <varname>xxx</varname> &egrave; un numero determinato dai primi byte
      dell'eseguibile. Cos&igrave; la configurazione di kerneld per
      supportare il modulo binfmt_aout per gli eseguibili ZMAGIC
      (a.out) &egrave;:</para>

<screen>
  alias binfmt-267 binfmt_aout
</screen>

      <para>poich&eacute; il magic number per i file ZMAGIC &egrave; 267. Se si
      controlla il file <filename>/etc/magic</filename> si trover&agrave;
      0413. Si tenga presente che <filename>/etc/magic</filename> usa
      numeri in formato ottale, mentre kerneld usa il formato decimale
      e il numero 413 in base ottale corrisponde al numero decimale
      267.</para>

      <para>In realt&agrave; ci sono tre varianti leggermente diverse per gli
      eseguibili a.out (NMAGIC, QMAGIC e ZMAGIC), cos&igrave; per un pieno
      supporto del modulo binfmt_aout abbiamo bisogno di:</para>

<screen>
  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)
</screen>

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

      </sect2>

      <sect2 id="ldisc"><title>Discipline di linea (slip, cslip e
      ppp)</title>

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

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

<screen>
  alias tty-ldisc-3 bsd_comp
  alias ppp0 bsd_comp
</screen>

      </sect2>

      <sect2 id="net-pf"><title>Famiglie di protocolli di rete (IPX,
      AppleTalk, AX.25)</title>

      <para>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
      <literal>net-pf-</literal><varname>X</varname>, dove
      <varname>x</varname> &egrave; un numero che sta ad indicare la famiglia
      voluta. Per esempio <literal>net-pf-3</literal> &egrave; AX.25,
      <literal>net-pf-4</literal> &egrave; IPX e <literal>net-pf-5</literal>
      &egrave; AppleTalk (questi numeri sono determinati dalle definizioni
      AF_AX25, AF_IPX, etc. nel file sorgente di Linux
      <filename>include/linux/socket.h</filename>). Cos&igrave; per caricare
      automaticamente il modulo IPX &egrave; necessario aggiungere al file
      <filename>/etc/conf.modules</filename> una linea come
      questa:</para>

<screen>
  alias net-pf-4 ipx
</screen>

      <para>Si veda anche la sezione riguardante i <xref
      linkend="commonproblems"> per informazioni su come evitare
      alcuni noiosi messaggi all'avvio relativi a famiglie di
      protocolli indefiniti.</para>

      </sect2>

      <sect2 id="fs"><title>I file system</title>

      <para>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&egrave; per il filesystem di tipo
      iso9660:</para>

<screen>
  alias iso9660 isofs
</screen>

      </sect2>
    </sect1>

    <sect1 id="special-devs"><title>Periferiche che richiedono
    una configurazione speciale</title>

    <para>Alcune periferiche richiedono una configurazione che va
    leggermente al di l&agrave; del semplice uso di alias di una periferica
    per un modulo.</para>

      <itemizedlist>
        <LISTITEM><PARA>Periferiche a caratteri a major number 10:
        <link linkend="misc-devs">periferiche
        varie</link></PARA></LISTITEM>

        <LISTITEM><PARA><link linkend="scsidevs">Periferiche
        SCSI</link> </PARA></LISTITEM>

        <LISTITEM><PARA><link linkend="pre-post">Periferiche che
        richiedono inizializzazioni speciali</link></PARA></LISTITEM>
      </itemizedlist>

      <sect2 id="misc-devs"><title>char-major-10 : mouse, watchdog e casualit&agrave;</title>

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

        <itemizedlist>
          <LISTITEM><PARA>mouse di vario genere (bus mouse, mouse
          PS/2),</PARA></LISTITEM>

          <LISTITEM><PARA>periferiche watchdog,</PARA></LISTITEM>

          <LISTITEM><PARA>il dispositivo <filename>random</filename>
          del kernel,</PARA></LISTITEM>

          <LISTITEM><PARA>interfaccia APM (Advanced Power
          Management).</PARA></LISTITEM>

        </itemizedlist>

        <para>Queste periferiche sono controllate da altrettanti
        moduli, non da uno solo. Perci&ograve; la configurazione di kerneld
        per queste <emphasis>periferiche eterogenee</emphasis> fa uso
        del major number <emphasis>e</emphasis> del minor
        number:</para>

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

        <para>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.</para>

      </sect2>

      <sect2 id="scsidevs"><title>Caricamento di driver SCSI: la voce
      <literal>scsi_hostadapter</literal></title>

        <para>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&agrave; a nastro). Tutti
        possono essere caricati come moduli. Perci&ograve;, quando desidera
        accedere, per esempio, al lettore di CD-ROM connesso alla
        scheda Adaptec, il kernel e kerneld sanno solo che c'&egrave; bisogno
        di caricare il modulo <filename>sr_mod</filename> per
        supportare il CD-ROM SCSI, ma non sanno a quale controller il
        CD-ROM &egrave; connesso n&egrave;, tanto meno, quale modulo caricare per
        supportare il controller SCSI.</para>

        <para>Per risolvere questo problema si pu&ograve; aggiungere una voce
        per il driver SCSI al proprio
        <filename>/etc/conf.modules</filename> che dica a kerneld
        quale dei possibili moduli per controller SCSI deve
        caricare:</para>

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

        <para>Questo funziona solo con versioni del kernel 1.3.82 o
        superiori.</para>

        <para>Il metodo va bene se si possiede un solo controller
        SCSI. Se ce ne sono pi&ugrave; d'uno, le cose diventano un po' pi&ugrave;
        difficili.</para>

        <para>In generale &egrave; possibile fare in modo che kerneld carichi
        un driver per un adattatore SCSI se un driver per un altro
        adattatore SCSI &egrave; gi&agrave; installato. Si &egrave; costretti a compilare
        entrambi i driver direttamente nel kernel (non come moduli) o
        caricare i moduli manualmente.</para>

        <tip><para>Tuttavia un modo per caricare pi&ugrave; driver SCSI
        <emphasis>esiste</emphasis>. James Tsiao ha avuto questa idea:</para>

          <blockquote>
             <para>&Egrave; facile fare in modo che kerneld carichi il
             secondo driver scsi: basta impostare le dipendenze in
             <filename>modules.dep</filename> a mano. Serve solo una
             voce come:</para>

<screen>
      /lib/modules/2.0.30/scsi/st.o: /lib/modules/2.0.30/scsi/aha1542.o
</screen>

             <para>per far caricare a kerneld aha1542.o prima che
             carichi st.o. La mia macchina a casa &egrave; configurata
             praticamente come sopra e tutto funziona bene per le mie
             periferiche scsi secondarie, inclusa l'unit&agrave; a nastro, il
             CD-ROM e le periferiche scsi generiche. L'altra faccia
             della medaglia sta nel fatto che <command>depmod
             -a</command> non pu&ograve; rilevare automaticamente queste
             dipendenze, cos&igrave; l'utente ha bisogno di aggiungerle
             manualmente e non pu&ograve; lanciare <command>depmod
             -a</command> all'avvio. Ma, una volta che tutto &egrave;
             configurato, kerneld caricher&agrave; in automatico l'aha1542.o
             senza problemi.</para></blockquote></tip>

          <para>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&agrave; a nastro o periferiche SCSI
          generiche sull'altro).</para>

      </sect2>

      <sect2 id="pre-post" xreflabel="comando pre/post-install">
        <title>Quando caricare un modulo non &egrave; sufficiente: la voce
        <literal>post-install</literal> entry</title>

        <para>Qualche volta caricare solo il modulo non &egrave; abbastanza
        per far funzionare le cose. Per esempio, se la seconda scheda
        sonora &egrave; stata compilata come modulo, spesso &egrave; conveniente
        impostare un certo livello per il volume. L'unico problema &egrave;
        che l'impostazione svanisce quando viene caricato il modulo
        un'altra volta. Ecco, in breve, un trucco di Ben Galliart
        (<email>bgallia@luc.edu</email>):</para>

        <blockquote>
          <para>La soluzione definitiva ha richiesto l'installazione
          del <ulink
          url="ftp://sunsite.unc.edu/pub/Linux/apps/sound/mixers/">pacchetto
          <productname>setmix</productname></ulink> e l'aggiunta delle
          seguenti linee al mio
          <filename>/etc/conf.modules</filename>:</para>

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

</blockquote>

          <para>Questa linea fa in modo che kerneld, dopo che il
          modulo per l'audio &egrave; stato caricato, lanci il comando
          indicato dalla voce <literal>post-install sound</literal>.
          Cos&igrave; il modulo sonoro viene configurato con il comando
          <command>/usr/local/bin/setmix -f
          /etc/volume.conf</command>.</para>

          <para>Ci&ograve; pu&ograve; essere utile anche per altri moduli, per
          esempio il modulo <filename>lp</filename> pu&ograve; essere
          configurato con il programma <filename>tunelp</filename>
          aggiungendo:</para>

<programlisting>
        post-install lp tunelp options
</programlisting>

          <para>Affinch&eacute; kerneld recepisca queste opzioni, si
          necessit&agrave; di una versione di kerneld 1.3.69f o
          superiore.</para>


        <note>
          <para>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&ograve; nonostante questa opzione non ha mai funzionato
          e il suo uso &egrave; perci&ograve; scoraggiato (pi&ugrave; appropriatamente,
          questa opzione scomparir&agrave; 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.</para>
        </note>

      </sect2>
    </sect1>

    <sect1 id="spying"><title>Spiare kerneld</title>

      <para>Se &egrave; stata provata qualsiasi cosa e non &egrave; proprio stato
      possibile immaginare cosa il kernel sta chiedendo di fare a
      kerneld, c'&egrave; un modo di vedere le richieste che kerneld riceve
      e, da questo, capire cosa deve andare in
      <filename>/etc/conf.modules</filename>: l'utilit&agrave; kdstat.</para>

      <para>Questo piccolo e grazioso programma fa parte del pacchetto
      dei moduli, ma non viene compilato n&egrave; installato per default.
      Per ottenerlo &egrave; sufficiente andare nella directory dove
      risiedono i sorgenti di kerneld e digitare <command>make
      kdstat</command>. Poi, per fare in modo che kerneld mostri
      informazioni su cosa sta facendo, lanciare <command>kdstat debug
      </command> e kerneld comincer&agrave; a vomitare messaggi sulla console
      riferendo cosa sta facendo. Se poi si prova ad eseguire il
      comando che si desidera utilizzare, si vedranno comparire le
      richieste di kerneld; queste possono essere messe in
      <filename>/etc/conf.modules</filename> utilizzando un alias per
      il modulo necessario a completare il lavoro.</para>

      <para>Per fermare la fase di debug, eseguire un
      <command>/sbin/kdstat nodebug</command>.</para>

    </sect1>

    <sect1 id="goodies"><title>Usi particolari di
    kerneld</title>

      <para>Lo sapevo che volevi chiedere come impostare il modulo per
      lo screen-saver!</para>

      <para>La directory <filename>kerneld/GOODIES</filename> del
      pacchetto dei moduli ha un paio di patch per il supporto di
      kerneld di screen-saver e del beep della console; queste non
      fanno ancora parte del kernel ufficiale, cos&igrave; sar&agrave; necessario
      installarle e ricompilare il kernel.</para>

      <para>Per installare una patch si usa il comando
      <command>patch</command>:</para>

<screen>
  cd /usr/src/linux
  patch -s -p1 /usr/src/modules-*/kerneld/GOODIES/blanker_patch
</screen>

      <para>Poi ricompila ed installa il nuovo kernel.</para>

      <para>Quando lo screen-saver viene attivato kerneld eseguir&agrave; il
      comando <filename>/sbin/screen-blanker</filename> (questo file
      pu&ograve; essere qualsiasi cosa, per esempio uno script di shell che
      lancia il proprio screen-saver preferito).</para>

      <para>Quando il kernel vuole ripristinare lo schermo invia un
      segnale <token>SIGQUIT</token> al processo che sta eseguendo
      <filename>/sbin/screenblanker</filename>. Lo script di shell
      deve poterlo catturare e terminare. Ricordarsi di ripristinare
      lo schermo alla modalit&agrave; testo originale!</para>

    </sect1>

    <sect1 id="commonproblems" xreflabel="problemi comuni">
      <title>Problemi comuni e cose di cui non si capisce il
      motivo</title>

      <qandaset>

        <qandaentry>
          <question>
            <para>Perch&eacute; ottengo il messaggio <errorname>Cannot locate
            module for net-pf-X</errorname> (Non riesco a trovare il
            modulo per net-pf-X) quando lancio
            <command>/sbin/ifconfig</command>?</para>
          </question>

          <answer>
            <para>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&ograve; caus&ograve; l'aggiunta di
            una nuova richiesta di kerneld:
            <literal>net-pf-</literal><varname>X</varname>, dove
            <varname>X</varname> &egrave; un numero che identifica il
            protocollo (vedi
            <filename>/usr/src/linux/include/linux/socket.h</filename>
            per il significato dei vari numeri). Sfortunatamente
            <command>ifconfig</command> provoca in modo accidentale
            questi messaggi, cosicch&eacute; molte persone ottengono un paio
            di messaggi di log quando il sistema viene avviato e viene
            lanciato <command>ifconfig</command> per configurare la
            periferica di loopback. Questi non indicano nulla di
            pericoloso ed &egrave; possibile disabilitarli aggiungendo le
            linee:</para>

<screen>
        alias net-pf-3 off      # Forget AX.25
        alias net-pf-4 off      # Forget IPX
        alias net-pf-5 off      # Forget AppleTalk
</screen>

            <para>a <filename>/etc/conf.modules</filename>.
            Ovviamente, se si utilizza IPX come modulo, non si deve
            aggiungere la linea che lo disabilita.</para>
          </answer>
        </qandaentry>

        <qandaentry>
          <question>
            <para>Dopo la partenza di kerneld il mio sistema viene
            messo in ginocchio quando attivo una connessione
            ppp</para>
          </question>

          <answer>
            <para>Ci sono stati un paio di casi riportati per questo
            problema. Sembra essere dovuto ad una sfortunata
            interazione fra kerneld e lo script
            <productname>tkPPP</productname> che viene usato su alcuni
            sistemi per impostare e monitorare la connessione PPP.
            Apparentemente lo script si morde la coda mentre esegue
            <command>ifconfig</command>. Questo richiama kerneld per
            cercare i moduli
            <literal>net-pf-</literal><varname>X</varname> (vedi
            sopra), tenendo il sistema in sovraccarico e generando,
            eventualmente, un sacco si messaggi del tipo
            <errorname>Cannot locate module for net-pf-X</errorname>
            nel log di sistema. Non si conosce alcun modo per
            aggirare il problema, se non quello di evitare
            <productname>tkPPP</productname> o di cambiarlo usando
            qualche altro modo per tenere sotto controllo la
            connessione.</para>
          </answer>
        </qandaentry>

        <qandaentry>
          <question>
            <para>kerneld non carica il mio driver
            SCSI!</para>
          </question>

          <answer>
            <para>Aggiungere una voce per il proprio adattatore SCSI
            al file <filename>/etc/conf.module</filename>. Si veda la
            descrizione della voce <link
            linkend="scsidevs"><literal>scsi_hostadapter</literal></link>
            pi&ugrave; sopra.</para>
          </answer>
        </qandaentry>

        <qandaentry>
          <question>
            <para>modprobe si lamenta che
            <errorname>gcc2_compiled</errorname> non &egrave;
            definito</para>
          </question>

          <answer>
            <para>Questo &egrave; un errore nelle utilit&agrave; dei moduli che si
            verifica solo con le binutils 2.6.0.9 e seguenti e che &egrave;
            anche documentato nelle note per le binutils. Si legga il
            documento in proposito oppure ci si procuri un
            aggiornamento per le utilit&agrave; dei moduli che porgano
            rimedio.</para>
          </answer>
        </qandaentry>

        <qandaentry>
          <question>
            <para>Il driver della mia scheda sonora continua a
            dimenticarsi le impostazioni per il volume,
            etc.</para>
          </question>

          <answer>
            <para>Le impostazioni per un modulo sono salvate
            all'interno del modulo stesso quando viene caricato.
            Cos&igrave;, quando kerneld auto-scarica un modulo, ogni
            impostazione fatta viene dimenticata e la volta successiva
            il modulo ritorna alle impostazioni di default.</para>

            <para>Si pu&ograve; dire a kerneld di configurare un modulo
            eseguendo un programma dopo che il modulo &egrave; stato
            auto-caricato. Vedere il <xref linkend="pre-post"> alla
            voce <literal>post-install</literal>.</para>
          </answer>
        </qandaentry>

        <qandaentry>
          <question>
            <para>DOSEMU ha bisogno di alcuni moduli. Come posso fare
            affinch&eacute; kerneld li carichi?</para>
          </question>

          <answer>
            <para>Non &egrave; possibile. Nessuna delle versioni di dosemu
            (ufficiali o di sviluppo) supporta il caricamento dei
            moduli di dosemu attraverso kerneld. Per&ograve;, se si utilizza
            un kernel 2.0.26 o successivi, non c'&egrave; pi&ugrave; bisogno di
            alcun modulo speciale dosemu. Semplicemente aggiornarsi
            alla versione 0.66.1.</para>
          </answer>
        </qandaentry>

        <qandaentry>
          <question>
            <para>Perch&eacute; ottengo un messaggio <errorname>Ouch, kerneld
            timed out, message failed</errorname> (Oops, tempo scaduto
            per kerneld, messaggio fallito)?</para>
          </question>

          <answer>
            <para>Quando il kernel invia una richiesta a kerneld, si
            aspetta di ottenere un &laquo;ricevuto&raquo; entro un secondo. Se
            kerneld non invia questo riscontro, il messaggio d'errore
            viene registrato nel log di sistema. La richiesta viene
            ritrasmessa e dovrebbe finalmente arrivare a
            destinazione.</para>

            <para>Questo di solito capita su sistemi con un carico
            elevato. Poich&eacute; kerneld &egrave; un processo eseguito in
            modalit&agrave; utente, esso viene &laquo;schedulato&raquo; come ogni altro
            processo sul sistema. In momenti di carico elevato, pu&ograve; non
            riuscire ad inviare per tempo il &laquo;ricevuto&raquo;, prima che
            scada il tempo per kernel.</para>

            <para>Se questo accade anche quando il carico &egrave; scarso, si
            provi a far ripartire kerneld. Uccidere il processo
            kerneld e farlo ripartire ancora con il comando
            <command>/usr/sbin/kerneld</command>. Se il problema
            persiste, si dovrebbe inviare un messaggio con l'errore a
            <email>linux-kernel@vger.rutgers.edu</email>, ma
            <emphasis>si prega</emphasis> di accertarsi che la propria
            versione di kernel, kerneld e delle utilit&agrave; per i moduli
            sia aggiornata prima di spedire messaggi sul problema.
            Controllare i prerequisiti in
            <filename>linux/Documentation/Changes</filename>.</para>
          </answer>
        </qandaentry>

        <qandaentry>
          <question>
            <para>mount non aspetta che kerneld carichi il modulo per
            il filesystem</para>
          </question>

          <answer>
            <para>Ci sono stati un certo numero di casi riportati per
            i quali il comando mount(8) non aspettava che kerneld
            finisse di caricare il modulo del filesystem.
            <command>lsmod</command> mostra che kerneld carica il
            modulo e, ripetendo il comando mount subito dopo, questo
            in effetti viene fatto. Questo sembra essere dovuto ad un
            errore nella versione 1.3.9f delle utilit&agrave; per i moduli
            che affligge alcuni utenti Debian. Pu&ograve; essere eliminato
            procurandosi una versione successiva delle utilit&agrave; per i
            moduli.</para>
          </answer>
        </qandaentry>

        <qandaentry>
          <question>
            <para>kerneld fallisce nel caricare il modulo
            <literal>ncpfs</literal></para>
          </question>

          <answer>
            <para>&Egrave; necessario compilare le utilit&agrave; per ncpfs con
            l'opzione <token>-DHAVE_KERNELD</token>. Vedere il
            <filename>Makefile</filename> di
            <productname>ncpfs</productname>.</para>
          </answer></qandaentry>

        <qandaentry>
          <question>
            <para>kerneld fallisce nel caricare il modulo per
            <filename>smbfs</filename></para>
          </question>

          <answer>
            <para>Si sta usando un versione delle utilit&agrave; per
            <productname>smbmount</productname> troppo vecchia. Ci si
            procuri l'ultima versione (0.10 o successive) dall'<ulink
            url="ftp://tsx-11.mit.edu/pub/linux/filesystems/smbfs/">archivio
            SMBFS su TSX-11</ulink></para>
          </answer>
        </qandaentry>

        <qandaentry>
          <question>
            <para>Ho compilato tutto come modulo e ora il mio sistema
            non si avvia pi&ugrave; o kerneld non riesce a caricare il modulo
            del root filesystem!</para>
          </question>

          <answer>
            <para>Non &egrave; possibile rendere modulare
            <emphasis>tutto</emphasis>: il kernel deve avere
            abbastanza driver compilati normalmente affinch&eacute; sia
            capace di fare il mount del filesystem principale ed
            eseguire i programmi necessari ad avviare
            kerneld<footnote><para>In effetti questo non &egrave; vero.
            L'ultimo kernel 1.3.x e tutti i 2.x supportano l'uso di un
            ram-disk iniziale che viene caricato da LILO o LOADLIN, ed
            &egrave; possibile caricare moduli da questo &laquo;disco&raquo; molto presto
            all'interno del processo di avvio. Il procedimento per
            farlo &egrave; descritto in
            <filename>linux/Documentation/initrd.txt</filename>
            contenuto con i sorgenti del kernel.</para></footnote>.
            Cos&igrave; non puoi rendere modulare:</para>

            <itemizedlist>
              <LISTITEM><PARA>il driver per l'hard-disk sul quale
              risiede il filesystem principale;</PARA></LISTITEM>

              <LISTITEM><PARA>il driver del filesystem
              stesso;</PARA></LISTITEM>

              <LISTITEM><PARA>il caricatore del formato binario di
              init, kerneld e altri programmi.</PARA></LISTITEM>
            </itemizedlist>
          </answer></qandaentry>

        <qandaentry>
          <question>
            <para>kerneld non viene caricato all'avvio; si lamenta di
            libgdbm</para>
          </question>

          <answer>
            <para>Le versioni pi&ugrave; recenti di kerneld hanno bisogno
            delle librerie GNU dbm, le
            <filename>libgdbm.so</filename>, per girare. Molte
            installazioni hanno questo file in
            <filename>/usr/lib</filename>, mentre si sta probabilmente
            lanciando kerneld prima che il filesystem per
            <filename>/usr</filename> sia stato montato. Un sintomo
            di questo &egrave; che kerneld non parte durante l'avvio (dagli
            script rc), ma va bene se lo si lancia manualmente dopo
            che il sistema &egrave; partito. La soluzione consiste nello
            spostare l'avvio di kerneld dopo che sia stato fatto il
            mount di <filename>/usr</filename> oppure spostare la
            libreria gdbm sul filesystem principale, per esempio in
            <filename>/lib</filename>.</para>
          </answer>
        </qandaentry>

        <qandaentry>
          <question>
            <para>Ottengo un <errorname>Cannot load module
            xxx</errorname> (Non posso caricare il modulo
            <varname>xxx</varname>), ma ho appena riconfigurato il
            kernel senza il supporto per
            <varname>xxx</varname>!</para>
          </question>

          <answer>
            <para>L'installazione Slackware (probabilmente anche altre) crea
            un file <filename>/etc/rc.d/rc.modules</filename> che
            opera un esplicito modprobe su una variet&agrave; di moduli.
            Quali moduli esattamente vengano testati dipende dalla
            configurazione originale del kernel. Probabilmente si &egrave;
            riconfigurato il kernel escludendo uno o pi&ugrave; dei moduli
            che vengono testati nel proprio rc.modules, da cui il
            messaggio/i di errore. Aggiornare il proprio
            <filename>rc.modules</filename> commentando ogni modulo
            che non viene pi&ugrave; utilizzato, o cancellare
            <filename>rc.modules</filename> completamente e lasciare
            che kerneld carichi i moduli quando ne ha bisogno.</para>
          </answer>
        </qandaentry>

        <qandaentry>
          <question>
            <para>Ho ricompilato il kernel ed i moduli ma continuo ad
            ottenere messaggi di simboli non risolti
            all'avvio</para>
          </question>

          <answer>
            <para>Probabilmente il kernel &egrave; stato
            riconfigurato/ricompilato escludendo alcuni moduli, ma ci
            sono ancora alcuni vecchi moduli non pi&ugrave; utilizzati sparsi
            in giro per la directory
            <filename>/lib/modules</filename>. La soluzione pi&ugrave;
            semplice &egrave; quella di cancellare la directory
            <filename>/lib/modules/</filename><varname>x.y.z</varname>
            e dare un altro <command>make modules_install</command>
            dalla directory dei sorgenti del kernel. Nota che questo
            problema capita solo quando si riconfigura il kernel senza
            cambiare versione. Se si nota questo errore quando si sta
            eseguendo un aggiornamento ad una versione pi&ugrave; nuova, il
            tipo di problema &egrave; un altro.</para>
          </answer>
        </qandaentry>

        <qandaentry id="kernel2-1-problems" xreflabel="problemi comuni">
          <question>
            <para>Ho installato Linux 2.1/2.3 e ora non riesco pi&ugrave; a
            caricare <emphasis>nessun</emphasis>
            modulo!</para>
          </question>

          <answer>
            <para>Numeri dispari di Linux indicano kernel di sviluppo.
            Come tale ci si pu&ograve; aspettare che le cose smettano di funzionare di
            quando in quando. Una delle cose che &egrave; cambiata in
            maniera significativa &egrave; il modo con il quale vengono
            trattati i moduli e dove il kernel e i moduli vengono
            caricati in memoria.</para>

            <para>In breve, se si desidera utilizzare i moduli con un
            kernel di sviluppo, si deve:</para>

            <itemizedlist>
              <LISTITEM><PARA>leggere il file
              <filename>Documentation/Changes</filename> e vedere
              quali pacchetti hanno bisogno di essere aggiornati sul
              sistema</PARA ></LISTITEM>

              <LISTITEM ><PARA>usare l'ultimo pacchetto modutils,
              disponibile sotto <ulink
              url="ftp://ftp.redhat.com/pub/alphabits/">AlphaBits da
              Red Hat</ulink> o dal sito mirror <ulink
              url="ftp://tsx-11.mit.edu/pub/linux/packages/alphabits/">TSX-11</ulink></PARA></LISTITEM>
            </itemizedlist>

            <para>Si raccomanda di utilizzare almeno un kernel 2.1.29
            se si desidera usare i moduli con un kernel 2.1.</para>
          </answer>
        </qandaentry>

        <qandaentry>
          <question>
            <para>E a proposito del collegamento alla rete su
            richiesta?</para>
          </question>

          <answer>
            <para>kerneld originariamente aveva qualche supporto per
            stabilire una connessione di rete in dial-up su richiesta;
            provare a spedire pacchetti ad una rete senza essere
            connessi, faceva lanciare a kerneld lo script
            <filename>/sbin/request_route</filename> per instaurare la
            connessione PPP o SLIP.</para>

            <para>Questo si rivel&ograve; essere una cattiva idea. Alan Cox,
            personaggio illustre nel networking di Linux, scrisse sulla
            mailing-list linux-kernel:</para>

            <blockquote>
              <para>Il materiale su request_route &egrave; obsoleto,
              inefficiente e inutile [...]. Inoltre &egrave; stato rimosso
              dall'albero 2.1.x.</para></blockquote>

            <para>Invece di usare lo script request-route e kerneld,
            consiglio vivamente di installare il <ulink
            url="http://www.dna.lth.se/~erics/diald.html">pacchetto
            diald </ulink> di Eric Schenk.</para>
          </answer>
        </qandaentry>
      </qandaset>
    </sect1>

</article>

<!--
Local Variables:
mode:sgml
sgml-doctype:("kerneld.sgml" "article" "chapter")
sgml-insert-missing-element-comment: nil
sgml-indent-step: 2
sgml-default-dtd-file:"kerneld.ced"
End:
-->
