FOSS-Inside: Kernel Mode Settings e oltre

Una passeggiata tra Kernel e X Server. Parlare tecnicamente di Kernel Mode Setting non è banale, bisogna giocoforza parlare del Kernel e dell’X Server e di come queste due entità interagiscono.

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.

L’introduzione del Kernel Mode Setting ha comportato una evoluzione di questa architettura, e non certamente uno stravolgimento.

Come detto poco sopra il KMS è stato introdotto nel Kernel Linux solo dopo la stabilizzazione del driver GEM. 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.

La descrizione che è stata fatta è molto di alto livello, sono stati tralasciati tutti gli aspetti relativi ai driver grafici presenti in X, così come tutto l’eventuale discorso relativo a Mesa e OpenGL, che sebbene non direttamente coinvolti potrebbero subire lievissime modifiche. L’idea di questo post è quella di fare il punto della situazione e di fornire spunti per ulteriori approfondimenti.

Per i curiosi, eccovi l’elenco delle IOCTL aggiunte: DRM_IOCTL_MODE_GETRESOURCES, DRM_IOCTL_MODE_GETCRTC, DRM_IOCTL_MODE_GETOUTPUT, DRM_IOCTL_MODE_SETCRTC, DRM_IOCTL_MODE_ADDFB, DRM_IOCTL_MODE_RMFB, DRM_IOCTL_MODE_GETFB. Ovviamente rimandiamo alla documentazione del Kernel Linux per una comprensione

No-Root X. In questi giorni si inizia a parlare di 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. Sulla mailing list del progetto Gnome si sta discutendo il come poter implementare la funzionalità, importando probabilmente parte del lavoro fatto per Moblin.

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. Date una occhiata alla discussione per farvi una idea.