Cosa è il Kernel Mode Setting? “Il Kernel Mode Setting è una funzionalità che consente di impostare la risoluzione dello schermo e la profondità del colore (il numero di bit utilizzati per rappresentare un singolo pixel grafico), così come altri parametri che hanno a che fare con l’inizializzazione della parte grafica.” Implementare il KMS nel Kernel Linux significa configurare all’avvio della macchina la scheda grafica secondo le impostazioni indicate dai parametri di boot. Come sappiamo lo stack grafico utilizzato per anni è diviso su più livelli, e non tutti interni al kernel: vga driver (kernel), framebuffer driver (kernel), DRM driver (kernel), X drivers (userspace), DRI e DDX driver (userspace), e altre librerie di gestione (userspace). Il Kernel Mode Setting implica lo spostare funzionalità dal layer userspace dell’X Server in quello interno al Kernel Linux. Il Kernel Linux 2.6.31 attualmente in fase di sviluppo potrebbe avere “un Kernel Mode Setting molto più maturo”. Già a partire dalla Release Candidate 1, infatti, è stato reso noto che si stanno stabilizzando il più possibile i driver ATI e nVidia in merito proprio all’utilizzo del KMS. I driver Intel invece sono stati fin da subito capaci di gestire il KMS (ndr almeno su Moblin).
I vantaggi del KMS. Il Kernel Mode Setting apporterà vantaggi a diversi livelli. Ecco i principali:
* Il controllo delle impostazioni verrà spostato e “centralizzato” nel Kernel Linux. Un solo modulo sarà coinvolto con conseguente minore ridondanza di codice, snellimento e uniformità delle procedure di gestione, nonché riduzione dei livelli software “attraversati”;
* Sarà possibile implementare “un processo di boot più fluido”, con un’unica splash grafica dall’avvio del kernel fino all’entrata nel desktop grafico, e senza reset del monitor o riscalature grafiche;
* La gestione “del suspend e del resume” dell’hardware grafico avverà tutta nel kernel, anche in questo caso il tutto risulterà più veloce e snello;
* Sarà possibile eseguire un “Server X come utente non privilegiato” (No-Root X), e questo a tutto vantaggio della sicurezza del sistema;
* Si potrà ipotizzare la scrittura di “un nuovo driver del framebuffer”, più veloce e funzionale;
* Il Kernel Linux potrà gestire delle “splash grafiche di diagnostica”, per mostrare agli utenti in maniera più semplice eventuali messagi di warning (”blue penguin of death”).
Parlare tecnicamente di Kernel Mode Setting non è banale, bisogna prima di tutto sapere come il Kernel e X Server interagiscono tra di loro. Un buon punto di partenza può essere la documentazione del modulo DRI, e in particolare il Control Flow Diagram riportato sul sito ufficiale del progetto. Questo diagramma mostra i componenti che vengono usati quando l’X Server, o più in generale un applicativo grafico che usa l’infrastruttura X.Org, disegna un oggetto grafico.
I blocchi in alto corrispondono agli applicativi utente, il blocco in basso rappresenta il kernel e l’hardware grafico, nel mezzo trovate una serie di blocchetti che corrispondo alle librerie e ai demoni coinvolti nell’operazione di Rendering. Tipicamente il server X può accedere all’hardware grafico in due modi: passando per il modulo DDX o per quello DRI/DRM (Direct Rendering). Nel caso dell’accesso DDX il server X usa questo modulo come intermediario, passandogli i comandi e i dati di rendering. Il modulo DDX a sua volta accede all’hardware grafico passando o meno per il kernel. Nel caso dell’accesso DRI/DRM invece il server X, o chi per esso, comunica direttamente con l’hardware grafico, eliminando un passaggio e accelerando il tutto (meno copie di dati, e accesso diretto alla RAM mappata). In questo caso la libreria DRI in userspace si interfaccia col driver DRM in kernel space che gli fornisce l’accesso desiderato. Il principale componente che lavora sul KMS è il driver DRM, che ora implementa delle nuove IOCTL per l’accesso da user space, cioè da parte degli applicativi grafici. La riscrittura del driver DRM ha comportato una revisione delle librerie in user space, è nata così la libreria DRI2. Il modulo DDX, come si può apprendere anche dal Wiki di X.Org, è stato snellito di molto. Il processo di boot cambia. All’avvio la gestione dell’inizializzazione grafica verrà fatta dal Kernel, mentre l’X Server dovrà eventualmente preoccuparsi solo di impostare i corretti parametri, cioè risoluzione, profondità di colore, frequenza di refresh, e così via. Ovviamente se i parametri impostati dal Kernel Linux sono gli stessi usati dall’X Server allora la reimpostazione non sarà necessaria e questo a vantaggio dell’utente finale che non accuserà il passaggio dall’uno all’altro gestore grafico. Un’altra piccola rivoluzione che il Kernel Mode Setting si porta dietro ed è quella del No-Root X, ovvero dell’X Server eseguito come utente non privilegiato. Da quel che sembra l’X Server ha bisogno dei diritti di root per 5 motivi:
1. I/O probing;
2. tty/VT probing e controllo;
3. invocazione di IOCTL del driver DRM;
4. PCI probing;
5. Gestione input;
Di questi cinque punti quelli che più bloccano l’esecuzione di X come utente non root sono il primo, il terzo e il quarto; il KMS sembra sbloccarli. Per i punti 2 e 5 esistono delle soluzioni alternative a quelle attuali, e che passano per librerie wrapper e il sistema di sicurezza PAM. Per saperne di piu , vi rimandiamo alla documentazione del Kernel Linux per una comprensione piu approfondita. Gli utenti Ubuntu al momento possono seguire due strade. Possono provare ad installare un kernel 2.6.30 secondo quanto indicato sul Wiki, e questo dovrebbe andare bene per chi ha una scheda grafica Intel. Gli utenti che hanno una scheda grafica nVidia o ATI possono invece utilizzare una delle due spanshot di Ubuntu 9.10 rilasciate dal team “xorg crack pushers” sui canali PPA di Canonical. Occhio, Ubuntu non ha ancora un supporto completo al KMS. Chi invece vuole usare il KMS di Moblin deve semplicemente allinearsi all’ultima versione di questa distribuzione e installarla ovviamente su un dispositivo compliant, il che vuol dire su una macchina con Intel Atom e processore grafico Intel.
* Sarà possibile implementare “un processo di boot più fluido”, con un’unica splash grafica dall’avvio del kernel fino all’entrata nel desktop grafico, e senza reset del monitor o riscalature grafiche;
* La gestione “del suspend e del resume” dell’hardware grafico avverà tutta nel kernel, anche in questo caso il tutto risulterà più veloce e snello;
* Sarà possibile eseguire un “Server X come utente non privilegiato” (No-Root X), e questo a tutto vantaggio della sicurezza del sistema;
* Si potrà ipotizzare la scrittura di “un nuovo driver del framebuffer”, più veloce e funzionale;
* Il Kernel Linux potrà gestire delle “splash grafiche di diagnostica”, per mostrare agli utenti in maniera più semplice eventuali messagi di warning (”blue penguin of death”).
Parlare tecnicamente di Kernel Mode Setting non è banale, bisogna prima di tutto sapere come il Kernel e X Server interagiscono tra di loro. Un buon punto di partenza può essere la documentazione del modulo DRI, e in particolare il Control Flow Diagram riportato sul sito ufficiale del progetto. Questo diagramma mostra i componenti che vengono usati quando l’X Server, o più in generale un applicativo grafico che usa l’infrastruttura X.Org, disegna un oggetto grafico.
I blocchi in alto corrispondono agli applicativi utente, il blocco in basso rappresenta il kernel e l’hardware grafico, nel mezzo trovate una serie di blocchetti che corrispondo alle librerie e ai demoni coinvolti nell’operazione di Rendering. Tipicamente il server X può accedere all’hardware grafico in due modi: passando per il modulo DDX o per quello DRI/DRM (Direct Rendering). Nel caso dell’accesso DDX il server X usa questo modulo come intermediario, passandogli i comandi e i dati di rendering. Il modulo DDX a sua volta accede all’hardware grafico passando o meno per il kernel. Nel caso dell’accesso DRI/DRM invece il server X, o chi per esso, comunica direttamente con l’hardware grafico, eliminando un passaggio e accelerando il tutto (meno copie di dati, e accesso diretto alla RAM mappata). In questo caso la libreria DRI in userspace si interfaccia col driver DRM in kernel space che gli fornisce l’accesso desiderato. Il principale componente che lavora sul KMS è il driver DRM, che ora implementa delle nuove IOCTL per l’accesso da user space, cioè da parte degli applicativi grafici. La riscrittura del driver DRM ha comportato una revisione delle librerie in user space, è nata così la libreria DRI2. Il modulo DDX, come si può apprendere anche dal Wiki di X.Org, è stato snellito di molto. Il processo di boot cambia. All’avvio la gestione dell’inizializzazione grafica verrà fatta dal Kernel, mentre l’X Server dovrà eventualmente preoccuparsi solo di impostare i corretti parametri, cioè risoluzione, profondità di colore, frequenza di refresh, e così via. Ovviamente se i parametri impostati dal Kernel Linux sono gli stessi usati dall’X Server allora la reimpostazione non sarà necessaria e questo a vantaggio dell’utente finale che non accuserà il passaggio dall’uno all’altro gestore grafico. Un’altra piccola rivoluzione che il Kernel Mode Setting si porta dietro ed è quella del No-Root X, ovvero dell’X Server eseguito come utente non privilegiato. Da quel che sembra l’X Server ha bisogno dei diritti di root per 5 motivi:1. I/O probing;
2. tty/VT probing e controllo;
3. invocazione di IOCTL del driver DRM;
4. PCI probing;
5. Gestione input;
Di questi cinque punti quelli che più bloccano l’esecuzione di X come utente non root sono il primo, il terzo e il quarto; il KMS sembra sbloccarli. Per i punti 2 e 5 esistono delle soluzioni alternative a quelle attuali, e che passano per librerie wrapper e il sistema di sicurezza PAM. Per saperne di piu , vi rimandiamo alla documentazione del Kernel Linux per una comprensione piu approfondita. Gli utenti Ubuntu al momento possono seguire due strade. Possono provare ad installare un kernel 2.6.30 secondo quanto indicato sul Wiki, e questo dovrebbe andare bene per chi ha una scheda grafica Intel. Gli utenti che hanno una scheda grafica nVidia o ATI possono invece utilizzare una delle due spanshot di Ubuntu 9.10 rilasciate dal team “xorg crack pushers” sui canali PPA di Canonical. Occhio, Ubuntu non ha ancora un supporto completo al KMS. Chi invece vuole usare il KMS di Moblin deve semplicemente allinearsi all’ultima versione di questa distribuzione e installarla ovviamente su un dispositivo compliant, il che vuol dire su una macchina con Intel Atom e processore grafico Intel.
Nessun commento:
Posta un commento