City_Hunter
29-05-2004, 17:06
Qualche tempo fa, in un momento di sana e lucida volontà masochistica, ho provato ad aggiornare il kernel di Linux passando dal 2.4.26 al 2.6.6.
Come molti sapranno, le serie che portano numeri pari (2.2, 2.4, 2.6) sono quelle giudicate stabili ed adoperabili in ambienti di produzione. Molte distribuzioni supportano già attivamente la nuova serie 2.6 , Slackware Linux ha deciso di procedere in modo più cauto.
Sebbene la nuova serie sia stata preceduta dalla lunga fila di kernel 2.5 che hanno permesso di rilevare errori e migliorare via via le nuove caratteristiche, è indubbio che con l'arrivo della serie 2.6 più gente abbia cominciato ad usare il nuovo kernel stabile e quindi sia iniziata una fase di test più consistente, legata all'utilizzo quotidiano.
Istruzioni per l'uso e moduli esterni
Chi abbia seguito recentemente il changelog (http://www.slackware.org/changelog/) di slackware-current, avrà avuto modo di vedere come molti dei recenti aggiornamenti siano stati pensati per una futura migrazione indolore al kernel 2.6.
Questo è vero specialmente per gli init scripts, tra i numerosi cambiamenti c'è ora il mount automatico su /sys del nuovo sysfs qualora gli scripts rilevino che il kernel usato è, per l'appunto, un 2.6.
Dunque un upgrade a slackware-current, almeno per quel che riguarda il gruppo A (quello contenente programmi e scripts basilari), è straconsigliato.
In secondo luogo è necessario verificare il supporto del kernel 2.6 per tutti i driver che si adopera e che non sono inclusi nel kernel di linux. Infatti i moduli esterni al kernel progettati per il kernel 2.4 NON funzionano col kernel 2.6.
Nel mio caso:
eagle-usb (http://eagle-usb.ath.cx/pub/) per il modem ADSL, a partire dalla recente versione 1.9.6 supporta il kernel 2.6.x. E' consigliabile comunque estrarre l'ultima versione del driver da CVS perchè la serie 2.6.x è in continua evoluzione. Per esempio un driver scritto per 2.6.4 potrebbe avere piccole difficoltà a compilare col 2.6.6 (in effetti per eagle-usb è proprio così, a causa di modifiche di struct per USB nel codice).
linux-wlan-ng (http://www.linux-wlan.org) per le schede wireless; il supporto per 2.6 esiste, è dichiarato sperimentale. In realtà sulla mia piccola rete ad-hoc si è rivelato finora affidabilissimo e nella ML del driver ho trovato molta disponibilità per la segnalazione di eventuali problemi.
nvidia linux driver (http://www.nvidia.com/object/linux.html) per la mia geforce. Supporto per kernel 2.6 presente e perfettamente funzionante. Meglio di così...
Non so quanti abbiano ancora un vetusto scanner su porta parallela, io ce l'ho. Il driver del kernel pt_drv per plustek_pp (sane-project (http://www.sane-project.org/)) esiste e compila anche su 2.6, ma per qualche oscura ragione non rileva il mio Primax 4800 Direct (mentre sul 2.4 non c'erano problemi). Poco male, basta utilizzare la modalità diretta al posto della modalità kernel e si risolve.
Menzione a parte merita il progetto lm-sensors (http://secure.netroedge.com/~lm78/), dedicato al controllo di salute dell'hardware (temperature, ventole, tensione). Sul kernel 2.4 era necessario compilare esternamente al kernel i vari moduli i2c. Sul 2.6 i moduli sono tutti presenti (e selezionabili) direttamente nel kernel, dunque è opportuno installare solo gli applicativi userspace del pacchetto lm-sensors.
I driver audio sono quelli del progetto ALSA (http://www.alsa-project.org/) (uno dei fiori all'occhiello di Linux, ndG), che sostituiscono i driver OSS oramai obsoleti. Sul 2.4 era necessario compilare i driver ALSA esternamente al kernel (gli unici presenti nel kernel erano i driver OSS), sul 2.6 sono presenti entrambi i driver. Personalmente sul kernel non compilo moduli sonori, preferisco in ogni caso compilare i moduli ALSA esternamente in ogni caso per poter scegliere la loro versione a mio piacimento.
Questi sono i driver esterni al kernel che ero solito compilare con il kernel 2.4, se qualcuno ne usa altri ovviamente dovrà verificare il relativo supporto al nuovo 2.6.
Vantaggi e svantaggi
Ma alla fine, vantaggi nell'usare la serie 2.6 rispetto alla 2.4, ci sono?
Risposta: si.
Basterebbe dire che molte cose sono state riscritte meglio, ma siccome la maggior parte delle persone si limita ad usare Linux e non certo ad andarne a vedere il codice, preferisco evidenziare semplici riscontri pratici.
Ecco alcune delle cose che ho notato usando quotidianamente un kernel 2.6.
Il kernel 2.6 supporta senza bisogno di alcuna patch il CPU frequency scaling (ossia la possibilità di ridurre la freuqenza di lavoro del proprio processore e il relativo consumo energetico). Su un desktop questa caratteristica è inutile, ma è semplicemente -vitale- per un portatile alimentato dalla sua batteria, che si desidera far durare il più a lungo possibile.
Chiunque abbia un masterizzatore IDE sa che sul kernel 2.4 era necessario, per la scrittura, farlo apparire come dispositivo SCSI tramite l'emulatore ide-scsi (compilando apposta l'intero stack SCSI, passando un opportuno parametro al kernel, ecc.ecc.) . Con il kernel 2.6 è possibile (e di fatto è anche più efficiente) scrivere direttamente da ide-cd. Niente più ide-scsi. Ho già collaudato questa possibilità oltre la teoria, e ne sono rimasto molto soddisfatto.
Low-latency e preemptible kernel sono patch particolarmente adoperate nei sistemi desktop su kernel 2.4. Il kernel 2.6 supporta nativamente queste caratteristiche, in particolare l'opzione di preempt è disponibile in fase di configurazione. Molti sostengono di avere una sensazione di maggiore responsività del sistema usando il kernel 2.6, personalmente già adoperavo le patch di cui sopra (adesso note come patch -lck (http://www.plumlocosoft.com/kernel/)) e ho trovato un ambiente ugualmente idoneo per eventuali applicazioni real-time (come i sequencer midi).
Sul kernel 2.6 c'è anche il supporto nativo per IPsec (non ha a che vedere col progetto FreeS/WAN), molto importante per la creazione di reti sicure, attivabile nelle opzioni di configurazione per la rete.
Vi segnalo anche le nuove interfacce grafiche per la configurazione del kernel.
Sebbene fossi oramai abituato al classico make xconfig e relativo schema Tcl/Tk, pare che in tanti abbiano gradito molto le nuove interfacce basate su Qt (make xconfig o make qconfig) e GTK (make gconfig). In effetti quella basata su Qt è carina e ordinata.
Sicuramente c'è ancora un bel pò di lavoro da fare sul kernel 2.6, per esempio ultimamente sono stati riscontrati alcuni rallentamenti nell'I/O dei file (http://kerneltrap.org/node/view/3039) rispetto al 2.4, nel caso in cui alcuni thread provino a leggere simultaneamente dallo stesso descrittore di file. Il problema dovrebbe essere già stato risolto nella rc-1 del 2.6.7, ma aspetterò il 2.6.7 final per verificare.
Sempre a proposito di scheduler: Con Kolivas, che si è occupato in passato di mantenere le patch -ck (quelle relative a low-latency e preemption che ora il 2.6 supporta di suo), si occupa ora di nuove patch (come lo staircase scheduler) (http://members.optusnet.com.au/ckolivas/kernel/) per il miglioramento della responsività del kernel 2.6.
Su kernel.org è possibile anche reperire le patch -mm (http://www.kernel.org/patchtypes/mm.html) di Andrew Morton che a detta di molti suoi utilizzatori migliorano le prestazioni tramite l'approccio sperimentale (nuovi scheduler e altro). Se questo sia vero o meno non lo so, ma ho una mezza idea di sperimentarle con il 2.6.7 :)
Come molti sapranno, le serie che portano numeri pari (2.2, 2.4, 2.6) sono quelle giudicate stabili ed adoperabili in ambienti di produzione. Molte distribuzioni supportano già attivamente la nuova serie 2.6 , Slackware Linux ha deciso di procedere in modo più cauto.
Sebbene la nuova serie sia stata preceduta dalla lunga fila di kernel 2.5 che hanno permesso di rilevare errori e migliorare via via le nuove caratteristiche, è indubbio che con l'arrivo della serie 2.6 più gente abbia cominciato ad usare il nuovo kernel stabile e quindi sia iniziata una fase di test più consistente, legata all'utilizzo quotidiano.
Istruzioni per l'uso e moduli esterni
Chi abbia seguito recentemente il changelog (http://www.slackware.org/changelog/) di slackware-current, avrà avuto modo di vedere come molti dei recenti aggiornamenti siano stati pensati per una futura migrazione indolore al kernel 2.6.
Questo è vero specialmente per gli init scripts, tra i numerosi cambiamenti c'è ora il mount automatico su /sys del nuovo sysfs qualora gli scripts rilevino che il kernel usato è, per l'appunto, un 2.6.
Dunque un upgrade a slackware-current, almeno per quel che riguarda il gruppo A (quello contenente programmi e scripts basilari), è straconsigliato.
In secondo luogo è necessario verificare il supporto del kernel 2.6 per tutti i driver che si adopera e che non sono inclusi nel kernel di linux. Infatti i moduli esterni al kernel progettati per il kernel 2.4 NON funzionano col kernel 2.6.
Nel mio caso:
eagle-usb (http://eagle-usb.ath.cx/pub/) per il modem ADSL, a partire dalla recente versione 1.9.6 supporta il kernel 2.6.x. E' consigliabile comunque estrarre l'ultima versione del driver da CVS perchè la serie 2.6.x è in continua evoluzione. Per esempio un driver scritto per 2.6.4 potrebbe avere piccole difficoltà a compilare col 2.6.6 (in effetti per eagle-usb è proprio così, a causa di modifiche di struct per USB nel codice).
linux-wlan-ng (http://www.linux-wlan.org) per le schede wireless; il supporto per 2.6 esiste, è dichiarato sperimentale. In realtà sulla mia piccola rete ad-hoc si è rivelato finora affidabilissimo e nella ML del driver ho trovato molta disponibilità per la segnalazione di eventuali problemi.
nvidia linux driver (http://www.nvidia.com/object/linux.html) per la mia geforce. Supporto per kernel 2.6 presente e perfettamente funzionante. Meglio di così...
Non so quanti abbiano ancora un vetusto scanner su porta parallela, io ce l'ho. Il driver del kernel pt_drv per plustek_pp (sane-project (http://www.sane-project.org/)) esiste e compila anche su 2.6, ma per qualche oscura ragione non rileva il mio Primax 4800 Direct (mentre sul 2.4 non c'erano problemi). Poco male, basta utilizzare la modalità diretta al posto della modalità kernel e si risolve.
Menzione a parte merita il progetto lm-sensors (http://secure.netroedge.com/~lm78/), dedicato al controllo di salute dell'hardware (temperature, ventole, tensione). Sul kernel 2.4 era necessario compilare esternamente al kernel i vari moduli i2c. Sul 2.6 i moduli sono tutti presenti (e selezionabili) direttamente nel kernel, dunque è opportuno installare solo gli applicativi userspace del pacchetto lm-sensors.
I driver audio sono quelli del progetto ALSA (http://www.alsa-project.org/) (uno dei fiori all'occhiello di Linux, ndG), che sostituiscono i driver OSS oramai obsoleti. Sul 2.4 era necessario compilare i driver ALSA esternamente al kernel (gli unici presenti nel kernel erano i driver OSS), sul 2.6 sono presenti entrambi i driver. Personalmente sul kernel non compilo moduli sonori, preferisco in ogni caso compilare i moduli ALSA esternamente in ogni caso per poter scegliere la loro versione a mio piacimento.
Questi sono i driver esterni al kernel che ero solito compilare con il kernel 2.4, se qualcuno ne usa altri ovviamente dovrà verificare il relativo supporto al nuovo 2.6.
Vantaggi e svantaggi
Ma alla fine, vantaggi nell'usare la serie 2.6 rispetto alla 2.4, ci sono?
Risposta: si.
Basterebbe dire che molte cose sono state riscritte meglio, ma siccome la maggior parte delle persone si limita ad usare Linux e non certo ad andarne a vedere il codice, preferisco evidenziare semplici riscontri pratici.
Ecco alcune delle cose che ho notato usando quotidianamente un kernel 2.6.
Il kernel 2.6 supporta senza bisogno di alcuna patch il CPU frequency scaling (ossia la possibilità di ridurre la freuqenza di lavoro del proprio processore e il relativo consumo energetico). Su un desktop questa caratteristica è inutile, ma è semplicemente -vitale- per un portatile alimentato dalla sua batteria, che si desidera far durare il più a lungo possibile.
Chiunque abbia un masterizzatore IDE sa che sul kernel 2.4 era necessario, per la scrittura, farlo apparire come dispositivo SCSI tramite l'emulatore ide-scsi (compilando apposta l'intero stack SCSI, passando un opportuno parametro al kernel, ecc.ecc.) . Con il kernel 2.6 è possibile (e di fatto è anche più efficiente) scrivere direttamente da ide-cd. Niente più ide-scsi. Ho già collaudato questa possibilità oltre la teoria, e ne sono rimasto molto soddisfatto.
Low-latency e preemptible kernel sono patch particolarmente adoperate nei sistemi desktop su kernel 2.4. Il kernel 2.6 supporta nativamente queste caratteristiche, in particolare l'opzione di preempt è disponibile in fase di configurazione. Molti sostengono di avere una sensazione di maggiore responsività del sistema usando il kernel 2.6, personalmente già adoperavo le patch di cui sopra (adesso note come patch -lck (http://www.plumlocosoft.com/kernel/)) e ho trovato un ambiente ugualmente idoneo per eventuali applicazioni real-time (come i sequencer midi).
Sul kernel 2.6 c'è anche il supporto nativo per IPsec (non ha a che vedere col progetto FreeS/WAN), molto importante per la creazione di reti sicure, attivabile nelle opzioni di configurazione per la rete.
Vi segnalo anche le nuove interfacce grafiche per la configurazione del kernel.
Sebbene fossi oramai abituato al classico make xconfig e relativo schema Tcl/Tk, pare che in tanti abbiano gradito molto le nuove interfacce basate su Qt (make xconfig o make qconfig) e GTK (make gconfig). In effetti quella basata su Qt è carina e ordinata.
Sicuramente c'è ancora un bel pò di lavoro da fare sul kernel 2.6, per esempio ultimamente sono stati riscontrati alcuni rallentamenti nell'I/O dei file (http://kerneltrap.org/node/view/3039) rispetto al 2.4, nel caso in cui alcuni thread provino a leggere simultaneamente dallo stesso descrittore di file. Il problema dovrebbe essere già stato risolto nella rc-1 del 2.6.7, ma aspetterò il 2.6.7 final per verificare.
Sempre a proposito di scheduler: Con Kolivas, che si è occupato in passato di mantenere le patch -ck (quelle relative a low-latency e preemption che ora il 2.6 supporta di suo), si occupa ora di nuove patch (come lo staircase scheduler) (http://members.optusnet.com.au/ckolivas/kernel/) per il miglioramento della responsività del kernel 2.6.
Su kernel.org è possibile anche reperire le patch -mm (http://www.kernel.org/patchtypes/mm.html) di Andrew Morton che a detta di molti suoi utilizzatori migliorano le prestazioni tramite l'approccio sperimentale (nuovi scheduler e altro). Se questo sia vero o meno non lo so, ma ho una mezza idea di sperimentarle con il 2.6.7 :)