Contact me sending an e-mail (antispam defense activated)
Title: I moduli del kernel Author: Sandro Tosi Last modified: 2004-10-11 Le distribuzioni tendono a distribuire un kernel ridotto all'osso, necessario soltanto ad eseguire i compiti fondamentali, con tutto il resto compilato come modulo, caricabile on-the-fly in caso di bisogno. Inoltre, e` anche una pratica comune, in opposizione ad un kernel monolitico, compilare solo lo stretto necessario e lasciare i supporti a periferiche poco utilizzare (driver per l'USB, la scheda audio, la porta parallela) compilati come moduli da caricare quando diventa necessario. Avere pratica con i moduli diventa molto utile. Ecco un elenco delle azioni piu` comuni con i moduli. o Caricare moduli al boot Alcuni moduli sono necessari all'avvio del sistema (per esempio quello per il filesystem di /) mentre altri possono essere caricati anche in seguito, durante la fase di boot (quelli per la scheda di rete, ad esempio): si possono inserire nel file ``/etc/modules'' i nomi dei moduli da caricare. In Debian, e` possibile usare anche ``modconf'', uno strumento semi-visuale (basato su ncurses) per modificare questo file. o Caricare un modulo Per caricare un modulo ci sono due modi: # insmod <module> # modprobe <module> La differenza risiede, in particolare, nel fatto che ``modprobe'' cerca di risolvere le dipendenze con gli altri moduli, mentre ``insmod'' no. Un modulo puo` anche essere caricato automaticamente quando si accede ad un certo device; nel file ``/etc/modules.conf'' viene mantenuta la mappa delle corrispondenze modulo/device. In Debian abbiamo una utility, ``update-modules'', che si occupa di automatizzare il processo di manutenzione di questo file. o Rimuovere un modulo E` possibile che non sia consentito rimuovere dei moduli (principalmente per motivi di sicurezza); quando questo e` possibile si puo` eseguire # rmmod <module> o Elencare i moduli attualmente caricati # lsmod o Informazioni su un modulo # modinfo <module> o Generare il file delle dipendenze dei moduli Perche` la gestione dei moduli avvenga in modo corretto, e` necessario avere un albero delle dipendenze tra moduli; questa avviene tramite il comando ``depmod'': al boot, spesso viene rigenerato questo albero, ma e` comunque possibile farlo anche da noi: # depmod -a <kernel_version> che rigenera il file delle dipendenze, ``modules.dep'', all'interno della directory /lib/modules/<kernel_version>/ . o Moduli del kernel 2.6 Con l'introduzione della nuova release stabile del kernel, la 2.6, il formato dei moduli e` cambiato; insieme ad esso, e` cambiata anche l'estensione passando da ``.o'' (quella normale per ogni ``object'' compilato) a ``.ko'' (``Kernel Object''). A causa di questo cambiamento, e` necessario aggiornare le module-init-tool o Utilizzo di un modulo binario precompilato Molte aziende non distribuiscono i sorgenti dei propri moduli (vedi nVidia per le sue schede video) ma solo una loro versione binaria. Non e` una pratica che mi rende molto tranquillo (chi controlla cosa c'e` dentro?) ma spesso e` l'unico modo per poter utilizzare il proprio hardware. In teoria, un modulo per essere utilizzabile ``in sicurezza'' con un kernel dovrebbe essere stato compilato per la stessa versione di quello nel quale vogliamo inserirlo e con la stessa versione del compilatore utilizzato per il kernel (non sempre questo e` vero), ma soprattutto devono essere rispettate le dipendenze: se inserisco un modulo che richiede il supporto SCSI ed esso non e` presente, non voglio nemmeno immaginare che potrebbe succedere... ;) Le aziende, invece, solitamente forniscono una sorta di ``nucleo'' binario che poi deve essere ``adattato'' al proprio environment: di solito si tratta di linkare alcune parti del kernel e delle libc necessari per sapere quali simboli usare e quali syscall esportare.