LKMPG: Ciao Mondo: differenze tra le versioni

nuova categoria
(nuova categoria)
 
(4 versioni intermedie di 2 utenti non mostrate)
Riga 1: Riga 1:
{{Template:LKMPG}}
{{Template:LKMPG}}
==Ciao, Mondo (parte 1): Il modulo più semplice==
==Ciao, Mondo (parte 1): Il modulo più semplice==


Riga 119: Riga 118:
==Ciao, Mondo (parte 2)==
==Ciao, Mondo (parte 2)==


Dalla versione 2.4 del kernel Linux, si possono rinominare le funzioni di init e cleanup dei propri moduli; infatti non devono essere chiamate per forza rispettivamente <code>init_module()</code> e <code>cleanup_module</code>. Questo è reso possibile della macro <code>module_init()</code> e module_exit()</code>. Queste macro sono definite in <code>linux/init.h</code>. L'unica attenzione da avere è quella di definire le funzioni di init e cleanup prima di chiamare le macro, pena errori di compilazione. Vediamo un esempio di questa tecnica:
Dalla versione 2.4 del kernel Linux, si possono rinominare le funzioni di init e cleanup dei propri moduli; infatti non devono essere chiamate per forza rispettivamente <code>init_module()</code> e <code>cleanup_module</code>. Questo è reso possibile della macro <code>module_init()</code> e <code>module_exit()</code>. Queste macro sono definite in <code>linux/init.h</code>. L'unica attenzione da avere è quella di definire le funzioni di init e cleanup prima di chiamare le macro, pena errori di compilazione. Vediamo un esempio di questa tecnica:


'''Esempio 3-3. hello-2.c'''
'''Esempio 3-3. hello-2.c'''
Riga 515: Riga 514:
Per superare questo problema possiamo ricorrere all'opzione --force-vermagic, ma questa soluzione è potenzialmente insicura, e indiscutibilmente inaccettabile nella produzione di moduli. Di conseguenza, vogliamo compilare il nostro modulo in un ambiente che sia identico a quello in cui il nostro kernel precompilato è stato costruito. Come fare questo è il tema del resto del capitolo.
Per superare questo problema possiamo ricorrere all'opzione --force-vermagic, ma questa soluzione è potenzialmente insicura, e indiscutibilmente inaccettabile nella produzione di moduli. Di conseguenza, vogliamo compilare il nostro modulo in un ambiente che sia identico a quello in cui il nostro kernel precompilato è stato costruito. Come fare questo è il tema del resto del capitolo.


Prima di tutto, assicurarsi che il codice sorgente del kernel è disponibile e che abbia esattamente la stessa versione del kernel che in esecuzione. Dunque, trova il file di configurazione che è stato usato per compilare il kernel precompilato. Di solito, è disponibile nella directory /boot, sotto un nome tipo config-2.6.x. Potresti volerlo solo copiare nella directory del kernel: '''cp /boot/config-`uname -r` /usr/src/linux-`uname -r`/.config'''.
Prima di tutto, assicurarsi che il codice sorgente del kernel è disponibile e che abbia esattamente la stessa versione del kernel in esecuzione. Dunque, trova il file di configurazione che è stato usato per compilare il kernel precompilato. Di solito, è disponibile nella directory <code>/boot</code>, sotto un nome tipo config-2.6.x. Potresti volerlo copiare nella directory del kernel: '''cp /boot/config-`uname -r` /usr/src/linux-`uname -r`/.config'''.


Concentriamoci di nuovo sul precedente errore: uno sguardo da vicino alle stringe version magic suggeriscono che, anche con due file di configurazione che sono esattamente gli stessi, una piccola differenza nel version magic è possibile, ed è sufficiente a prevenire l'inserimento del modulo nel kernel. Questa piccola differenza, cioè la stringa personalizzata che appare nel version magic del modulo e non in quella del kernel, è dovuta ad una modifica nel makefile, che alcune distribuzioni includono, rispetto all'originale. Quindi, esamina il tuo /usr/src/linux/Makefile ed assicurati che l'informazione della versione specificata è esattamente la stessa di quella usata per il tuo kernel corrente. Per esempio, il tuo makefile potrebbe iniziare cosi:
Concentriamoci di nuovo sul precedente errore: uno sguardo da vicino alle stringhe version magic suggeriscono che, anche con due file di configurazione che sono esattamente gli stessi, una piccola differenza nel version magic è possibile, ed è sufficiente a prevenire l'inserimento del modulo nel kernel. Questa piccola differenza, cioè la stringa personalizzata che appare nel version magic del modulo e non in quella del kernel, è dovuta ad una modifica nel makefile, che alcune distribuzioni includono, rispetto all'originale. Quindi, esamina il tuo <code>/usr/src/linux/Makefile</code> ed assicurati che l'informazione della versione specificata è esattamente la stessa di quella usata per il tuo kernel corrente. Per esempio, il tuo makefile potrebbe iniziare cosi:


<pre>
<pre>
Riga 547: Riga 546:
</pre>
</pre>


Se non desideri compiare il kernel attualmente, puoi interrompere il processo ('''CTRL-C''') subito dopo la linea che inizia per <code>SPLIT</code> poichè in quel momento i file che ti servono saranno già pronti. Ora puoi tornare indietro alla directory del tuo modulo e compilarlo: sarà compilato correttamente in accordo con le impostazioni del tuo kernel corrente e verrà caricato senza nessun errore.
Se non desideri compiare il kernel ora, puoi interrompere il processo ('''CTRL-C''') subito dopo la linea che inizia per <code>SPLIT</code> poichè in quel momento i file che ti servono saranno già pronti. Ora puoi tornare indietro alla directory del tuo modulo e compilarlo: sarà compilato correttamente in accordo con le impostazioni del tuo kernel corrente e verrà caricato senza nessun errore.
 
[[Categoria:Linux Kernel Module Programming Guide]]
6 999

contributi