Lo strumento di cui sto parlando è ketchup, uno script in python sviluppato da Matt Mackall (manutentore del set di patch -tiny) ed è scaribabile da qui.
Per gli utenti Debian sarà sufficiente un:

# apt-get install ketchup

ketchup permette, tra le altre cose di:

• Scaricare e decomprimere l’ultima versione disponibile del kernel.
• Aggiornare una versione locale dei sorgenti, scaricando e applicando le dovute patch.
• Controllare le varie firme GPG dei sorgenti.
• Gestire i diversi rami (e set di patch) di linux, come -stable, -mm, -ck, -git, ecc…

Per prima cosa è necessario creare una cartella in cui verranno scaricati i sorgenti. La cartella consigliata è ‘/usr/src’ (ricordatevi di aggiungervi al gruppo ’src’), e, una volta lì:

$ mkdir dir
$ cd dir

Potete ovviamente dare il nome che volete alla cartella, vedremo in seguito che comunque verrà modificato.
Una volta nella cartella è venuto il momento di scaricare i sorgenti, ma prima è necessario decidere quale ramo del kernel utilizzare. Come forse saprete esistono diversi rami di sviluppo del kernel. I principali sono -stable (l’attuale versione stabile del kernel), -mm (la versione di sviluppo) e -git (l’ultimo snapshot dal repository git), ognuno di essi ovviamente presenta pregi e difetti, starà poi a voi decidere qual’è la più indicata (anche se mi sentirei di consigliare vivamente il ramo -stable, che, a meno che non siate sviluppatori, va più che bene).
Esistono inoltre diversi altri rami che rappresentano varie versioni modificate attraverso set di patch, in modo da rivestire particolari campi di applicazione: tra i principali ci sono le patch -rt (real-time), sviluppate da Ingo Molnar, indicate per quei sistemi in cui la latenza deve essere al minimo (vedi ad es registrazioni musicali), le -ck sviluppate da Con Kolivas, ideali per sistemi desktop in cui la responsività (responsiveness, suona meglio in inglese) è molto importante ed altre.
Per ottenere una lista completa e una breve descrizione dei rami supportati da ketchup è sufficiente:

$ ketchup -l

Scaricare il kernel

Una volta scelto il ramo (in questo il 2.6 che rappresenta lo -stable) è venuto il momento di scaricarlo, molto semplicemente:

$ ketchup 2.6

Sostituite ovviamente a 2.6 il ramo da voi scelto. “Questa operazione potrebbe richiedere qualche minuto” (cit.)

Una caratteristica piuttosto carina di ketchup, è quella di modificare il nome della cartella in cui viene scaricato il codice in base alla versione dello stesso, semplicemente aggiungendo l’opzione ‘-r’ o ‘--rename-directory’:

$ ketchup -r 2.6

Quindi se prima la cartella si chiamava ‘dir’, ora si chiamerà ‘linux-2.6.xx’ dove xx è l’attuale versione del kernel.
È inoltre possibile scaricare una particolare versione del kernel, come ad esempio la ‘2.6.22′ (giusto per prenderne una a caso):

$ ketchup -r 2.6.22

Una volta scaricata sarà comunque possibile aggiornarla all’ultima versione, sempre con:

$ ketchup -r 2.6

Tutto molto intuitivo.

Configurazione

È anche possibile gestire il comportamento di ketchup attraverso una file di configurazione: ‘~/.ketchuprc’. Le variabili disponibili sono pochine (solo tre) ma risultano più che utili.
Le variabili valide sono:

• default_tree – Che permette di impostare il ramo predefinito da cui scaricare il kernel e non sarà più quindi necessario passarlo via linea di comando; nel caso però che venga impostato via command-line verrà data priorità ad esso.
• precommand – Indica un comando da eseguire prima della sincronizzazione dei sorgenti.
• postcommand – Indica un comando da eseguire dopo la sincronizzazione dei sorgenti.

Per fare un esempio ecco il mio file ‘~/.ketchuprc’:

default_tree = "2.6"
postcommand = "rm ../linux && ln -s `pwd` ../linux"

Come potete vedere il ramo di sviluppo predefinito è il 2.6, mentre la variabile ‘postcommand’ è impostata in modo da aggiornare il link simbolico ‘/usr/src/linux’ alla nuova cartella (in pratica prima rimuove il vecchio link e poi lo ricrea passando la cartella corrente con ‘pwd’), da usare insieme a ‘--rename-directory’. La variabile ‘precommand’ è invece vuota perchè non mi serve a niente.

Questo è tutto, e come al solito, nel caso vogliate approfondire l’argomento, vi rimando al manuale:

$ man ketchup

Un interessante video by Greg Kroah-Hartman, uno dei maggiori sviluppatori del kernel Linux, su come applicare una patch al ramo stabile (-stable) di Linux. Mostra l’uso dei diversi strumenti e script utilizzati dagli sviluppatori (ketchup, quilt, git, mutt, patch, ecc…) rigorosamente da terminale, e come tutto il processo avviene.

Dategli un’occhiata se vi va, dura una decina di minuti, in lingua (scritta) inglese.

In questo articolo parlerò nuovamente di una funzione del kernel Linux: se nell’articolo precedente era kexec, in questo sarà lguest.
lguest non è altro che un hypervisor molto leggero (circa 5000 linee di codice), che permette in modo molto semplice di creare un sistema di paravirtualizzazione (non permette una virtualizzazione completa) con Linux (che è l’unica architettura supportata).
È formato da due parti distinte, una parte kernel, rappresentata da un modulo ‘lg’ (è anche possibile compilarlo direttamente nel kernel) che si occupa del lavoro sporco e una parte user-space, l’hypervisor.

Funzionamento

Il funzionamento di lguest è abbastanza semplice da comprendere, in quanto non impiega nessuna tecnica speciale come fanno altri sistemi tipo Xen.
Il cuore di tutto sta nel modulo del kernel che si occupa innanzitutto di allocare una porzione di meoria dinamica del kernel, in cui viene caricato un piccolo hypervisor incaricato di spostarsi dal kernel al sistema guest. Il processo di paravirtualizzazione viene compiuto grazie all’implementazione di paravirt_ops, che deve essere compilato nel kernel da eseguire come guest. Il modulo del kernel si occupa anche di fornire un’interfaccia tramite un file speciale posizionato in /dev/lguest. Il client in user-space, per creare un sistema guest, dovrà semplicemente scrivere un comando di inizializzazione in quel file indicando alcuni valori, come ad esempio dove trovare il kernel e la porzione di memoria da utilizzare.

A questo punto il client in user-space si occupa di allocare un tot di memoria virtuale che poi sarà mappata nel sistema guest come memoria fisica. In questa porzione viene caricato il kernel virtualizzato e poi l’user-space guest (in pratica il filesystem di root del sistema virtualizzato). Un semplice file può essere utilizzato per fornire al sistema guest un’immagine di un disco gestito dal client che si dovrà preoccuperà di spostare blocchi di dati nella memoria dinamica. Per quanto riguarda la rete, il creatore di lguest consiglia di utilizzare una periferica TAP configurata sul sistema host.
Per far partire il sistema guest, lg modifica opportunamente la page tables del kernel, per fare in modo che il sistema guest appena caricato

Bene o male questo è il funzionamento di lguest. Vediamo ora come mettere queste cose in pratica.

Root Filesystem

Iniziamo subito con la creazione di quello che sarà il filesystem di root del sistema guest. Sconsiglio vivamente di utilizzare una partizione esistente in quanto potrebbero sorgere problemi gravi.
Con questo procedimento verrà creato un sistema Debian da zero. È anche possibile trovare in rete immagini di altri sistemi (per quanto ne sappia, il team di Gentoo fornisce immagini di dischi con la distro preinstallata).

Prima di tutto creiamo il file nel quale verrà installato il sistema, come dimensione 1G dovrebbe bastare:

$ dd if=/dev/zero of=debian.img bs=1 count=1 seek=1G

Creiamo il filesystem:

# mke2fs -j -v debian.img

E montiamolo:

# mkdir /mnt/virtual
# mount debian.img /mnt/virtual -o loop

(potrebbe essere necessario caricare il modulo per il loopback)

Per installare il sistema base utilizzeremo un tool, debootstrap, che si occupa di scaricare e installare i pacchetti basilari per il nostro sistema. Dopo averlo installato:

# debootstrap --verbose --arch i386 squeeze /mnt/virtual http://debian.fastweb.it/debian

Potete ovviamente configurarlo come volete, modificando l’architettura, la versione di debian e il repository da cui prelevare i pacchetti.

Ora abbiamo un sistema perfettamente funzionante, ma che richiede alcune configurazioni aggiuntive prima di poter essere utilizzato con lguest.
Perciò la prima cosa da fare è entrare nel sistema con chroot:

# chroot /mnt/virtual

Da cui:

# apt-get update

Per una configurazione terra terra (orario + lingua + password root):

# dpkg-reconfigure tzdata
# apt-get install locales
# dpkg-reconfigure locales
# passwd root

Ora è necessario creare un device a blocchi che verrà utilizzato come console virtuale:

# mknod hvc0 c 229 0

e fare in modo che parta all’avvio modificando il file inittab:

# nano /etc/inittab

cambiando le linee che regolano l’avvio dei terminali:

1:2345:respawn:/sbin/getty hvc0
#2:2345:respawn:/sbin/getty tty2
#3:2345:respawn:/sbin/getty tty3
#4:2345:respawn:/sbin/getty tty4
#5:2345:respawn:/sbin/getty tty5
#6:2345:respawn:/sbin/getty tty6

Per finire creiamo un nuovo utente (chiamatelo pure come vi pare):

# adduser user

E poi usciamo

# exit

Kernel

Il modo più semplice per eseguire lguest, come suggerisce il creatore stesso, è utilizzare lo stesso kernel sia come host che come guest.
Abbiamo però bisogno di una configurazione particolare, quindi verificate le seguenti impostazioni nel vostro kernel (se non sono presenti ricompilate):

CONFIG_EXPERIMENTAL=y
CONFIG_PARAVIRT=y
CONFIG_LGUEST_GUEST=y
CONFIG_HIGHMEM64G=n
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_VIRTIO_BLK=m
CONFIG_VIRTIO_NET=m
CONFIG_TUN=m
CONFIG_LGUEST=m

Nella cartella del kernel ‘Documentation/lguest’ è presente il client user-space, se non è stato compilato con il kernel, digitate ‘make’.

A questo punto abbiamo tutto il necessario per avviare lguest.

Let’s virtualize

Per prima cosa è necessario caricare il modulo del kernel

# modprobe lg

Dopodichè, sempre dalla cartella di lguest

# ./lguest [mem] [kernel] --tunnet=[ip] --block=[rootfile] root=/dev/vda

Dove:

• [mem] indica la quantità di memoria da utilizzare in MB
• [kernel] il percorso del kernel da usare
• [ip] l’indirizzo di rete da attribuire al sistema guest
• [rootfile] il file da usare come root

Dopo aver definito root, è possibile indicare altri valori da passare al kernel.

Un esempio di utilizzo:

# ./lguest 64 /boot/vmlinuz-`uname -r` --tunnet=192.168.1.38 --block=debian.img root=/dev/vda ro quiet

debian.img starebbe ad indicare il file che abbiamo creato prima, mentre come kernel è stato impostato quello attualmente in uso.

Se tutto è andato per il verso giusto, il nuovo kernel dovrebbe partire.

Conclusione

La caratteristica più interessante di lguest è senza dubbio la sua facilità di comprensione e di utilizzo. Essendo scritto in quasi 5000 righe di codice non ha certo funzionalità avanzate da farlo competere con altri grossi progetti di virtualizzazione come Xen o KVM ma è senza dubbio un ottimo punto di partenza per meglio comprendere la virtualizzazione. E comunque non si può certo dire che su Linux manchino soluzioni per la virtualizzazione.

Su sistemi Linux alcuni dei pochi motivi per cui è necessario riavviare il sistema dipendono principalmente da: a) aggiornamento del kernel, b) crash dello stesso.

Personalmente ho sempre odiato il continuo bisogno di riavvio (spesso immotivato) in seguito ad un qualsiasi aggiornamento di software su sistemi Windows, è stata quindi una bella sorpresa per me scoprire che, come già detto, su Linux i riavvii sono molto rari.

Con l’aumentare della mia esperienza nell’uso di Linux, uno dei “lidi” su cui la mia curiosità si è posata è stato proprio il kernel. Dopo i miei primi e incerti tentativi di ricompilazione, credo di poter dire di aver raggiunto un ragguardevole livello di esperienza (per quanto un normale utente senza, ancora, nessuna istruzione accademica in materia possa raggiungere). Come a molti utenti Linux a me piace sperimentare, mi sono perciò spesso trovato a ricompilare uno stesso kernel diverse volte prima di raggiungere una configurazione che soddisfacesse pienamente le mie aspettative, e ovviamente a queste ricompilazioni seguivano necessariamente altrettanti riavvii del sistema. Questo fino a scoprire una interessante funzione del kernel Linux (entrata nel ramo principale di sviluppo già da diverso tempo): kexec.

Kexec permette, in poche parole, di riavviare un kernel da uno già in esecuzione senza dover necessariamente riavviare il sistema fisico.

Linux e il suo boot

Prima di partire però è necessario fare una piccola parentesi sul sistema di booting di Linux, questo per meglio comprendere come kexec funziona.
Il processo di boot ha due fasi principali, la fase del bootloader e quella del kernel, le quali possono essere suddivise a loro volta in diversi stadi.

La prima delle due, la fase bootloader, inizia quando un computer viene acceso fisicamente. Dopo qualche inizializzazioni, il controllo dell’avvio viene passato al BIOS (o firmware che dir si voglia), che ha il compito di determinare le varie periferiche connesse (memorie, dischi, ecc…). Il BIOS si occupa anche di avviare il bootloader dal master boot record (MBR), che, in base alla configurazione, farà decidere all’utente quale kernel avviare (la cosa è un pò più complicata, ma spiegare nei dettaglia il boot di Linux non è lo scopo di questo articolo). Ed è a questo pounto che si passa alla fase del kernel.

Dopo aver preso il controllo del boot, il kernel si occupa di esaminare le periferiche, caricare i driver necessari e inizializzarle. A questo punto vengono avviati i servizi di sistema che si occupano del resto (montare i filesystem, avviare i termiali, ecc…).

Per la fase di riavvio, prima di ritornare alla fase del bootloader, vengono prima terminati tutti i processi, smontati i filesystem e scaricati i driver (con conseguente spegnimento delle periferiche).

Cos’è kexec?

Kexec non è altro che una funzione del kernel Linux che permette di avviare un kernel da uno già avviato, saltando completamente la fase del bootloader sopra descritta, rendendo quindi la fase di riavvio molto più veloce. Si occupa, in altre parole, di caricare un nuovo kernel in memoria, terminare quello già in esecuzione e sostituirlo con quello caricato in precedenza.

Kexec si divide in due parti, la parte kernel, compilata direttamente con il kernel, che consiste in una serie di system call, e una parte user-space, chiamata kexec-tools (sono ovviamente necessarie entrambe).

Per verificare che il proprio kernel sia compilato con kexec, è sufficiente cercare nel file .config se la chiave CONFIG_KEXEC è impostata a ‘y’:

$ zgrep CONFIG_KEXEC /proc/config.gz

oppure

$ grep CONFIG_KEXEC /boot/config-`uname -r`

Mentre per la parte userspace è sufficiente installare kexec-tools

# apt-get install kexec-tools

oppure usando il proprio package manager preferito.

Come funziona?

Prima di procedere con la parte pratica, vediamo più in dettaglio come funziona kexec. Innanzitutto è necessario sapere che il kernel Linux deve essere avviato da una posizione predefinita della memoria, perciò per avviare un nuovo kernel è necessario sovrascrivere quello precedente. Questo è eseguito in 4 passaggi:

1. Caricare il nuovo kernel in memoria
2. Spostare il kernel nella memoria dinamica del kernel
3. Sostituire fisicamente il kernel caricato
4. Avviare il nuovo kernel

I primi due passaggi sono effettuati durante il caricamento del kernel. Una volta caricato nella memoria utente, il kernel viene spostato nella memoria dinamica del kernel grazie all’uso della chiamata di sistema ’sys_kexec’.
Insieme ad esso viene allocato in memoria del codice assembly chiamato ‘reboot_code_buffer’, che si dovrà occupare di sovrascrivere il kernel in funzione con quello caricato in memoria, e poi farlo partire (terzo e quarto passaggio).

kexec-tools

Dopo aver verificato che kexec sia correttamente compilato, e aver installato kexec-tools, vediamo ora come usare nella pratica questi strumenti.
Come già detto il primo passo è caricare il kernel in memoria (i primi due passaggi visti prima).

# kexec -l [nuovo-kernel] [args]

dove [nuovo-kernel] sta per l’immagine del kernel da caricare. I formati supportati sono: Beoboot-x86, elf-x86, bzImage-x86, multiboot-x86. Mentre [args] sta per gli argomenti specifici per i formati. Un esempio, utilizzando un kernel in formato bzImage, potrebbe essere:

# kexec -l /usr/src/linux/arch/i386/boot/bzImage --append="root=/dev/hdX"

Dove /dev/hdX sta per il filesystem di root. È possibile usare anche initrd:

# kexec -l /usr/src/linux/arch/i386/boot/bzImage --append="root=/dev/hdX" --initrd=/boot/initrd.img

Se siete indecisi su che argomenti passare al kernel potete dare un’occhiata al file ‘/proc/cmdline’ che indica i parametri dell’attuale kernel.
Per una lista di tutte le opzioni invece basta digitare:

$ man kexec

Ora non resta altro da fare che avviare il nuovo kernel.

# kexec -e

kexec avvia “alla brutta” il nuovo kernel senza fare lo shutdown correttamente, perciò consiglio di usare semplicemente il comando

# reboot

Che dovrebbe funzionare ugualmente (ad un certo punto, dovrebbe spuntare un scritta del tipo “rebooting with kexec” o qualcosa del genere).

Dopodichè il nuovo kernel dovrebbe partire, come se fosse un normale avvio del sistema.

Conclusione

Grazie a kexec, è possibile ridurre notevolmente i tempi di riavvio di un sistema, questo non solo beneficia uno sviluppatore che si trova a dover riavviare numerose volte, ma si applica molto bene anche a tutti quei sistemi in cui il downtime deve essere ridotto al minimo (la maggior parte dei sistemi enterprise quindi). Oltre che ovviamente a tutti quelli che come me vogliono solo imparare qualcosa di nuovo.

Compilato alla Debian way senza nessun problema, e felice come una pasqua mi apprestavo ad installare i driver nVidia… ed è proprio a questo punto che sono iniziati i problemi.

Primo tentativo usando module-assistant e il pacchetto nvidia-kernel-source (185.18)  da Sid… Fallito.

Secondo tentativo usando l’installer ufficiale nVidia (sempre 185.18)… Fallito.

Senza perdermi d’animo faccio un terzo tentativo usando l’installer nVidia ancora in beta (versione 192.32) ma anche questo fallisce.

A questo punto, insospettito, vado a guardare il log dell’installazione. L’errore riguardava una certa funzione init_MUTEX evidentemente modificata dalla patch RT. Cercando un pò su internet è saltato fuori che nell’ultima versione del kernel la patch non dichiarava più la suddetta funzione, rispetto alla precedente ovvero quella per la versione 2.6.29.

Continuando a cercare ho trovato anche un’ottima patch per risolvere il problema… vediamo ora come installarla.

La patch è la seguente:

diff -Naur NVIDIA-Linux-x86-190.32-orig/usr/src/nv/nv-linux.h NVIDIA-Linux-x86-190.32/usr/src/nv/nv-linux.h
--- NVIDIA-Linux-x86-190.32-orig/usr/src/nv/nv-linux.h	2009-09-02 11:54:49.000000000 +0100
+++ NVIDIA-Linux-x86-190.32/usr/src/nv/nv-linux.h	2009-09-17 21:05:45.000000000 +0100
@@ -742,20 +742,28 @@
 #define nv_down(lock)                   down(&lock)
 #define nv_up(lock)                     up(&lock)
 
+#if defined(CONFIG_PREEMPT_RT) && !defined(init_MUTEX)
+#  define nv_spin_lock_init(lock)              atomic_spin_lock_init(lock)
+#  define nv_spin_lock_irqsave(lock, irq)      atomic_spin_lock_irqsave(lock, irq)
+#  define nv_spin_unlock_irqrestore(lock, irq) atomic_spin_unlock_irqrestore(lock, irq)
+#else
+#  define nv_spin_lock_init(lock)              spin_lock_init(lock)
+#  define nv_spin_lock_irqsave(lock, irq)      spin_lock_irqsave(lock, irq)
+#  define nv_spin_unlock_irqrestore(lock, irq) spin_unlock_irqrestore(lock, irq)
+#endif
+
 #if defined(CONFIG_PREEMPT_RT)
-#define NV_INIT_MUTEX(mutex) init_MUTEX(mutex)
+#  if defined(init_MUTEX)
+#    define nv_spinlock_t raw_spinlock_t
+#  else
+#    define nv_spinlock_t atomic_spinlock_t
+#  endif
 #else
-#if !defined(__SEMAPHORE_INITIALIZER) && defined(__COMPAT_SEMAPHORE_INITIALIZER)
-#define __SEMAPHORE_INITIALIZER __COMPAT_SEMAPHORE_INITIALIZER
-#endif
-#define NV_INIT_MUTEX(mutex)                       \
-    {                                              \
-        struct semaphore __mutex =                 \
-            __SEMAPHORE_INITIALIZER(*(mutex), 1);  \
-        *(mutex) = __mutex;                        \
-    }
+#  define nv_spinlock_t   spinlock_t
 #endif
 
+#define NV_INIT_MUTEX(mutex) sema_init(mutex, 1)
+
 #if defined (KERNEL_2_4)
 #  define NV_IS_SUSER()                 suser()
 #  define NV_PCI_DEVICE_NAME(dev)       ((dev)->name)
diff -Naur NVIDIA-Linux-x86-190.32-orig/usr/src/nv/os-interface.c NVIDIA-Linux-x86-190.32/usr/src/nv/os-interface.c
--- NVIDIA-Linux-x86-190.32-orig/usr/src/nv/os-interface.c	2009-09-02 11:54:48.000000000 +0100
+++ NVIDIA-Linux-x86-190.32/usr/src/nv/os-interface.c	2009-09-17 21:05:45.000000000 +0100
@@ -108,11 +108,7 @@
 {
     nv_stack_t        *sp;
     struct completion  completion;
-#if defined(CONFIG_PREEMPT_RT)
-    raw_spinlock_t     lock;
-#else
-    spinlock_t         lock;
-#endif
+    nv_spinlock_t      lock;
     S032               count;
 } os_sema_t;
 
@@ -148,7 +144,7 @@
     os_sema = (os_sema_t *)*ppSema;
     os_sema->sp = sp;
     init_completion(&os_sema->completion);
-    spin_lock_init(&os_sema->lock);
+    nv_spin_lock_init(&os_sema->lock);
     os_sema->count = 1;
 
     if (nv_os_smp_barrier_init())
@@ -199,18 +195,18 @@
     os_sema_t *os_sema = (os_sema_t *)pSema;
     unsigned long old_irq;
 
-    spin_lock_irqsave(&os_sema->lock, old_irq);
+    nv_spin_lock_irqsave(&os_sema->lock, old_irq);
     if (os_sema->count <= 0)
     {
         os_sema->count--;
-        spin_unlock_irqrestore(&os_sema->lock, old_irq);
+        nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
         wait_for_completion(&os_sema->completion);
     }
     else
     {
         os_sema->count--;
         rm_disable_interrupts(os_sema->sp);
-        spin_unlock_irqrestore(&os_sema->lock, old_irq);
+        nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
     }
 
     return RM_OK;
@@ -233,17 +229,17 @@
     os_sema_t *os_sema = (os_sema_t *)pSema;
     unsigned long old_irq;
 
-    spin_lock_irqsave(&os_sema->lock, old_irq);
+    nv_spin_lock_irqsave(&os_sema->lock, old_irq);
     if (os_sema->count <= 0)
     {
-        spin_unlock_irqrestore(&os_sema->lock, old_irq);
+        nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
         return RM_ERROR;
     }
     else
     {
         os_sema->count--;
         rm_disable_interrupts(os_sema->sp);
-        spin_unlock_irqrestore(&os_sema->lock, old_irq);
+        nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
         return RM_OK;
     }
 
@@ -267,7 +263,7 @@
     unsigned long old_irq;
     BOOL doWakeup;
 
-    spin_lock_irqsave(&os_sema->lock, old_irq);
+    nv_spin_lock_irqsave(&os_sema->lock, old_irq);
     if (os_sema->count < 0)
     {
         doWakeup = TRUE;
@@ -278,7 +274,7 @@
         rm_enable_interrupts(os_sema->sp);
     }
     os_sema->count++;
-    spin_unlock_irqrestore(&os_sema->lock, old_irq);
+    nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
 
     if (doWakeup)
         complete(&os_sema->completion);
@@ -1383,7 +1379,7 @@
     unsigned long oldIrql;
 
     os_sema = (os_sema_t *) pSema;
-    spin_lock_irqsave(&os_sema->lock, oldIrql);
+    nv_spin_lock_irqsave(&os_sema->lock, oldIrql);
 
     return oldIrql;
 }
@@ -1394,7 +1390,7 @@
     unsigned long old_irq = (unsigned long) oldIrql;
 
     os_sema = (os_sema_t *) pSema;
-    spin_unlock_irqrestore(&os_sema->lock, old_irq);
+    nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
 }
 
 RM_STATUS NV_API_CALL os_get_address_space_info(

Si riferisce alla versione beta dei driver (192.32) quindi è necessario scaricarli dal sito ufficiale (ATTENZIONE: come già detto è solo una versione beta… maneggiare con cura ;) ).

Il secondo passo è quello di estrarre i sorgenti, per fare ciò utilizzare l’opzione ‘-x’:

$ sh NVIDIA-Linux-x86-190.32-pkg1.run -x

Che dovrebbe aver creato una cartella omonima (senza il .run). Ora creiamo una copia (non si sa mai):

$ cp -r NVIDIA-Linux-x86-190.32-pkg1 NVIDIA-Linux-x86-190.32-orig

Nel mio caso ho salvato la suddetta patch come ‘patch-2.6.31-nvidia-192.32-rt.patch’ nella stessa cartella di quella estratta prima (es. se ho estratto la cartella dei driver in ‘Downloads/NVIDIA-Linux-x86-190.32-orig’ il percorso della patch dovrà essere ‘Downloads/patch-2.6.31-nvidia-192.32-rt.patch’).

L’ultimo passo è quello di applicare la patch (alla vecchia maniera):

$ cat patch-2.6.31-nvidia-192.32-rt.patch | patch -p0

Il cui output dovrebbe essere qualcosa tipo:

patching file NVIDIA-Linux-x86-190.32-orig/usr/src/nv/nv-linux.h
patching file NVIDIA-Linux-x86-190.32-orig/usr/src/nv/os-interface.c

Se così non fosse, significherebbe che avete sbagliato qualcosa, perciò ripetete il procedimento da capo.

Ed ora possiamo tranquillamente installare i driver (dopo aver terminato Xorg):

$ sudo NVIDIA-Linux-x86-190.32-orig/nvidia-installer

Questo è tutto, dopo aver installato i driver è ovviamente necessario configurare Xorg, ma questa è un’altra storia, su interenet potete trovare pagine e pagine a riguardo.

Come forse saprete il kernel, è il nucleo di un sistema operativo. In Linux è possibile creare una versione personalizzata del kernel aumentando in questo modo l’efficienza e la stabilità del nostro sistema. Infatti in molte distribuzioni sono attivi in modo predefinito la maggior parte dei moduli, per vari motivi (e.g. per fare in modo che il sistema sia compatibile con la maggior parte di configurazioni hardware), rimuovendo quelli non necessari il kernel sel nostro sistema sarà più snello, e quindi più veloce ed efficiente e meno soggetto a problemi.

In Debian la ricompilazione del kernel può essere effettuata in diversi modi, quella standard per tutte le distribuzioni, o alla debian-way, che permette di compilare il kernel e di creare un comodo pacchetto .deb per facilitare la sua installazione (ed eventualmente la disinstallazione).

In questo articolo verrà illustrato il secondo metodo. I passi che vedremo saranno la configurazione del kernel, la sua compilazione e l’installazione.

Preparazione

Prima di cominciare è necessario installare alcuni pacchetti necessari alla compilazione e alla pachetizzazione del kernel

# apt-get install build-essential kernel-package fakeroot

Dopo aver fatto questo è necessario ottenere i sorgenti del kernel senza i quali non potremmo fare niente

$ apt-cache search linux-source
linux-source-2.6.24 - Linux kernel source for version 2.6.24 with Debian patches

I sorgenti del kernel presenti nei repository di Debian sono leggermente diversi da quelli del kernel Vanilla (rilasciati da Torvalds e dal suo staff), in quanto vengono leggermente modificati per meglio integrarli con il sistema. Per questo articolo prenderemo come esempio la versione 2.6.24, voi potete sostituirla con la versione che userete.
Ora non resta che installarli:

# apt-get install linux-source-2.6.24

L’archivio contenente tutti i file verrà posizionati in

/usr/src

Per evitare di compilare il kernel con i privilegi di root, è consigliato aggiungere l’utente che andrà a compilare, al gruppo “src”, i cui membri hanno diritto di scrittura nella cartella dei sorgenti

# adduser nome-utente src

Per rendere effettive le modifiche è necessario riloggarsi.

A questo punto possiamo spostarci nella cartella dei sorgenti

$ cd /usr/src

dove troveremo un archivio tar.bz2 contenente i sorgenti, da decomprimere

$ tar -jxvf linux-source-2.6.24.tar.bz2

Per facilitarci il lavoro creiamo un link simbolico alla cartella appena creata

$ ln -s linux-source-2.6.24 linux

E spostiamoci al suo interno

$ cd linux

Pulizia

Il prossimo passo da eseguire è la pulitura dei sorgenti. Questa operazione è necessaria per eliminare i file creati dalle precedenti compilazioni, se questa è la prima ricompilazione che eseguite non è necessaria.

$ make-kpkg clean

Configurazione

Passiamo ora alla configurazione, parte centrale dell’intera operazione. Per farlo si possono utilizzare differenti interfacce grafiche.

$ make config

Questa è l’interfaccia più semplice: presenta le varie opzioni una in seguito all’altra. Personalmente non mi piace molto, in quanto obbliga l’utente a definire qualsiasi tipo di impostazione, anche se non necessarie.

$ make menuconfig

Il metodo più comune: crea un comodo menu grazie alle librerie ncurses, in cui l’utente può facilmente navigare con la tastiera. Per questo metodo sono necessarie le librerie di sviluppo ncurses (ncurses-dev).

$ make xconfig

Simile al precedente metodo, con la differenza che il menu viene creato per X con le librerie qt.

$ make gconfig

Come sopra, ma con le librerie gtk.
Per questi due ultime modalità sono necessarie le librerie di sviluppo rispettivamente di qt e gtk.

A questo punto dovrete esplorare le varie opzioni del kernel, suddivise in diverse sezioni logiche. È possibile impostarle a off (ovvero non disponibile), modulo (compilato separatamente e caricato quando necessario) e on (compilato nel kernel).
In questo articolo non entrerò nel dettaglio delle varie opzioni, per avere maggiori dettagli potete consultare il Linux Kernel Configuration Archive, in cui non dovrete fare altro che selezionare la versione del kernel e l’architettura.
Una volta finito di configurare, e necessario salvare le impostazione selezionando l’apposita voce nel menu, che creerà un file di testo (in modo predefinito col nome “.config”) che potrà essere utilizzato anche in futuro per ulteriori compilazioni.
Ed ora la compilazione…

Compilazione

Per facilitare questa procedura useremo il tool make-kpkg, installato precedentemente

$ fakeroot make-kpkg --append-to-version custom --revision=1 kernel_image

È possibile anche creare pacchetti deb dai sorgenti di moduli (ad esempio alsa) posizionati in /usr/src/modules aggiungendo modules_image alla fine del comando, in modo che diventi

$ fakeroot make-kpkg --append-to-version custom --revision=1 kernel_image modules_image

Analizziamo brevemente questo comando:
–append-to-version custom – Serve ad aggiungere una stringa personalizzata (in questo caso “custom”) al nome del pacchetto, dopo il numero di versione, che verrà creato .
–revision=1 – Imposta un numero di revisione per il kernel, in modo che ad un successivo aggiornamento del kernel, quello personalizzato non venga rimosso in favore di quello ufficiale.
kernel_image – Indica che si vuole creare un pacchetto deb con il kernel compilato.

È possibile indicare altre opzioni, per una lista più approfondita vi rimando al manuale di make-kpkg

$ man make-kpkg

La compilazione richiederà un pò di tempo, al termine della quale verrà creato un file del tipo linux-image-<versione>-<nomepersonalizzato>-<architettura>.deb nella cartelle /usr/src.

Non ci resta altro da fare se non installarlo tramite dpkg.

# dpkg -i linux-image-2.6.24-custom-i386.deb

In seguito sarà possibile installare lo stesso kernel anche su altre macchine Debian senza dover eseguire un’altra volta tutta l’operazione.

Boot Loader

Ora che il nuovo kernel è installato potrebbe essere necessario aggiornare il boot loader.
Nel caso di grub questo non è necessario, in quanto dopo l’installazione di un nuovo kernel viene automaticamente eseguito un update-grub.
Nel caso di Lilo invece, è necessario modificare il file /etc/lilo.conf e aggiornare l’MBR.

A questo punto il nuovo kernel non è ancora in uso, per utilizzarlo è necessario riavviare la macchina e selezionarlo dal menu del boot loader.

Nel caso che qualcosa andasse storto, niente paura, riavviate il sistema con il vecchio kernel selezionandolo dal menu del boot loader.

E questo è tutto…