Molti dei drivers per linmodems sono disponibili solamente come moduli binari del kernel precompilati. Di norma, i moduli binari funzionano in modo trasparente solo con il kernel per il quale sono stati compilati. Per questo motivo, riuscire a far funzionare un driver precompilato con il vostro kernel particolare, può rivelarsi una vera sfida.
Dato che il kernel di Linux è un animale in perpetuo cambiamento, è una vera sfortuna che molti venditori di modem/chip non abbiano ancora optato per il rilascio dei sorgenti dei loro drivers, cosa che assicurerebbe la vostra e nostra possibilità di modificare appropriatamente detti drivers, man mano che i sorgenti del kernel si evolvono. Alcuni dei moduli binari sono stati forzati a funzionare sotto alcuni kernel più recenti utilizzando vari trucchi, come verrà descritto sotto; comunque, anche se un modulo fosse reso funzionale, è buona cosa usarlo il meno possibile. Citando una email da Mark Spieth,
"Un driver non potrà mai lavorare in maniera appropriata, se sono presenti dei simboli irrisolti, dato che ciò significa che c'è qualcosa che non funziona. In più vuol dire che quel qualcosa che avrebbe dovuto essere chiamata chiamerà una cosa diversa nel kernel e ciò potrebbe essere qualsiasi cosa. Ciò è molto male."
Quindi, siate cauti nell'utilizzare moduli binari con un kernel di versione differente; procedete a vostro rischio. Se reputate fondamentale che il vostro modem funzioni, considerate di tornare ad una versione precedente del kernel che corrisponda a quella del modulo - una prospettiva senza dubbio ridicola. Nonostante questi avvertimenti, comunque, molti hanno utilizzato kernel e moduli non corrispondenti, incontrando solo noie minori (occasionali kernel panic) usando i trucchi e strumenti come i seguenti.
Mark Spieth ha contribuito ad una serie progressivamente migliorata di "fixscripts",
per editare un modulo binario in maniera tale da eliminare gli avvertimenti di discrepanza di versione. L'inserzione del modulo così "fissato" procede senza l'opzione -f, cioè semplicemente insmod nome_del_modulo. Le versioni più recenti rinominano anche i simboli del modulo per farle corrispondere con quelle esportate dal kernel, in maniera tale che i messaggi di errore "Unresolved symbols" non vengano ritornati dal test depmod -e. Bisogna evidenziare che questi cambiamenti sono quasi esclusivamente cosmetici - è ancora raccomandabile utilizzare il modulo il meno possibile.
Per usare il fixscript su, per esempio, il modulo binario Lucent ltmodem.o (che non è attualmente il modulo da utilizzare), create una directory di lavoro, per esempio /root/modem.
Reperite l'ultima versione del fixscript da
http://www.test.dclabs.com.au/linmodem/fixscript.
Salvate il file come fixscript.
Esaminatelo con less o con il vostro editor preferito, per controllare che non siano stati aggiunti accidentalmente gli hard stops del DOS. Questi appaiono come M in grassetto oppure M sottolineate, oppure come ^M, a seconda del vostro viewer/editor. NOTA: il viewer more NON mostra gli hard stops del DOS.
Rendete in file eseguibile con chmod +x fixscript.
Generate un modulo "fissato" tramite, per esempio
./fixscript ltmodem.o ltmodem2217.o
Nessun messaggio di errore dovrebbe apparire testando le dipendenze con
depmod -e ltmodem2217.o
l'inserimento dovrebbe avere successo con un semplice, non forzato,
insmod ltmodem2217.o
Il "codice sorgente" fornito con alcuni moduli PCTel (un piccolo file in C) esegue un simile mascheramento quando compilato e linkato con le librerie binarie in quei pacchetti; al contrario il driver parzialmente open-source Lucent non compensa nessun cambiamento dell'interfaccia del kernel.
tty.h
Nella sua ricerca di far funzionare con kernel successivi al 2.2.14 il driver originale del modem Lucent LT (versione 5.68), totalmente binario, Mark Spieth ha notato che una semplice modifica nel kernel di Linux risolveva le principali incompatibilità occorse nel passaggio tra i kernels 2.2.14 e 2.2.16. Questo patch non è più necessario utilizzando il driver parzialmente binario e parzialmente sorgente (versione 5.78), ma resta utile per coloro con altri modems i cui drivers sia stati compilati con kernels pre-2.2.15.
Il 2.2.17 tty.h patchato ed alcuni pacchetti kernel 2.2.17 compilati con questo patch sono disponibili presso
http://walbran.org/sean/linux/stodolsk/.
Se preferite editare da voi il file, la linea da spostare è nella struttura
tty_struct all'interno di include/linux/tty.h; questo ha un membro aggiuntivo
poll_wait nei kernel più recenti.
Muovete questo membro alla fine della struttura, così che i restanti offsets saranno gli stessi delle versioni precedenti alla 2.2.15, per cui compatibili con il modulo precompilato. Dopo questa modifica al sorgente sarà necessario ricompilare kernel e moduli.
ppp.o dal Kernel 2.2.14
Esiste un trucco per l'uso di moduli binari con kernels successivi al 2.2.15, che nonne richiede la ricompilazione; comunque, dopo la scoperta del patch tty.h descritto sopra, questo trucco non è più necessario, né raccomandato. Ciò consiste nel sostituire il modulo /lib/modules/net/ppp.o con uno proveniente dal kernel 2.2.14. Christoph Hebeisen (cth(at)sfu.ca) ha riferito che l'uso di ppp.o versione 2.2.14 al posto della versione 2.2.16 con il modulo Lucent, ha fatto sì che funzionasse con kernels 2.2.16. Willie Green (willjr(at)lcc.net) ha confermato che tale trucco funziona anche con il modulo ESS. Dopo il semplice inserimento di un modulo di supporto versione-corrispondente:
insmod slhc
Si inserisce il ppp.o discrepante dal sorgente 2.2.14
insmod -f ppp.o
Desideriamo enfatizzare il fatto che questo trucco dell'inserimento forzato è meno stabile della facile è più efficace modifica al file sorgente del kernel tty.h, come descritto sopra.