2013-08-07 2 views
5

Ho un semplice oggetto kernel che ho creato per sondare la memoria del kernel.Modulo Kernel Linux (* .ko) compatibilità tra i kernel

Se lo compilo sulla mia macchina Ubuntu (3.2) a 64 bit, funziona bene su quella macchina. Ma non insmod sulla mia macchina Ubuntu (3.9) a 64-bit. E viceversa. Mi dà un errore "-1 modulo non valido" se cerco di eseguirlo su un Kernel rev diverso da quello su cui l'ho installato.

Ho pensato che insmod l'ha collegato dinamicamente alla tabella dei simboli esportata e la tabella dei simboli esportata non cambia tra le revisioni del kernel. (Viene aggiunto.)

Qualcuno può dirmi come posso creare un modulo del kernel (.ko) che sia compatibile con i kernel Linux futuri (o passati) senza dover essere ricostruito su quel kernel?

Ecco il mio file marca:

ccflags-y = -g

obj-m + = access_mem.o

tutto: make -C/lib/modules/$ (shell uname -r)/costruire M = $ (PWD) moduli

pulita: make -C/lib/modules/$ (shell uname -r)/costruire M = $ (PWD) puliti

+0

La tua Ubuntu 3.2 è una versione a 32-bit o 64-bit? Stessa domanda con Ubuntu 3.9 – nouney

+0

Entrambi a 64 bit. Grazie per avermi ricordato questo importante punto dati. –

risposta

5

Joe, Ubuntu (3.2) potrebbe utilizzare la versione del kernel x.y.z ma Ubuntu (3.9) potrebbe utilizzare la versione del kernel x.y.z1. Se le versioni del kernel differiscono, è necessario compilare/compilare il driver su quella particolare versione del kernel. Se le versioni del kernel sono uguali, non è necessario creare il driver. Il punto importante è che ogni modulo driver è stato compilato o costruito collegando con il modulo version.ko (che in realtà incorpora le informazioni sulla versione del kernel su cui è costruito il modulo driver), mentre carica il modulo del kernel controlla questa informazione e la versione del kernel, se diversa quindi getta "-1 Formato modulo non valido" o se abbinato, il modulo del kernel viene caricato correttamente. Per sviluppare il modulo del kernel che sia compatibile con il futuro o con le versioni precedenti è necessario sapere su quale versione del kernel quale firma dell'API o delle funzioni è stata modificata, ad esempio: firma ioctl modificata dalla versione 2.3.36 del kernel in poi, quindi il codice deve essere il seguente

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36) 
static long minor_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) 
#else 
static int minor_ioctl(struct inode *inode, struct file *filp, unsigned int cmd, 
                   unsigned long arg) 
#endif 

Se sviluppato in tal modo, il modulo del kernel è compatibile con il futuro o con le versioni precedenti. La compatibilità è solo adattamento di API o firma di funzione ecc. Modifiche per la versione del kernel preservando la vecchia API o firma di funzione ecc. Nel modulo del kernel come nell'esempio precedente, ma ancora è necessario compilare/compilare il modulo del kernel contro la versione del kernel su cui stai tentando di caricare.

+0

Quando ho scritto "(3.2)" e "(3.9)" intendevo "con la versione 3.2 del kernel" e "con la versione 3.9 del kernel", quindi sì thx. –

+0

In questo caso "insmod" è in realtà solo per gli sviluppatori. Non è mai stato concepito per l'inserimento di moduli binari predefiniti che sono stati distribuiti dalla società A direttamente all'immagine Linux esistente di B dell'utente finale. Concordato? –

+0

Joe, insmod è solo un'utilità per inserire binari precostruiti. Immagino che Insmod sia abbastanza intelligente da controllare la dipendenza dalla versione. Se le corrispondenze vengono caricate o genera un errore. http://tuxthink.blogspot.in/2010/09/insmod-explained.html –

1

sono non una e xpert sull'argomento ma sono abbastanza sicuro che devi costruire il tuo driver su ogni versione del kernel. Per quanto riguarda i simboli che rimangono gli stessi tra le versioni del kernel, sono abbastanza sicuro che non è vero dopo aver letto https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt.

+0

In tal caso "insmod" è in realtà solo per gli sviluppatori. Non è mai stato concepito per l'inserimento di moduli binari predefiniti che sono stati distribuiti dalla società A direttamente all'immagine Linux esistente di B dell'utente finale. Concordato? –

+0

Sono abbastanza sicuro che è possibile forzare i moduli di caricamento nel kernel, ovvero: i moduli creati per 3.9.10 possono essere caricati forzatamente in 3.10.4. – dklt

+0

Il caricamento forzato non è sicuro; potrebbe causare un arresto anomalo del sistema o, peggio. – Michael