Android e i cambiamenti apportati al kernel Linux
Rispolvero un minuto il blog, dato che ultimamente posto poco per il semplice fatto che tra lavoro e università, scrivere di cose che mi stiano a cuore con la testa "a posto" (ossia non presa da mille pensieri) mi riesce un po' arduo. Ma ho appena scovato una cosa interessante, che ha mi ha svoltato qualche ora della mia esistenza.
Vi siete mai chiesti quanti cambiamenti il progetto Android abbia mai apportato al kernel Linux per renderlo compatibile con il documento di progetto iniziale? Io spesso me lo sono chiesto. E a prescindere dal fatto che da qualche versione di Linux tutto il codice prima separato è confluito nel sorgente ufficiale, è una domanda che qualche volta mi sono fatto anch'io, concludendo con un sonoro boh ogni mia riflessione. Fortunatamente qualcuno ha deciso di chiederlo su Quora, e qualcun altro, uno sviluppatore Google, ha risposto.
Traduco in italiano perché merita:
La cosa interessante riguardo il design di Android è quanto poco abbiamo modificato il kernel. La maggior parte dei sistemi embedded su cui ho messo mano hanno apportato cambiamenti drastici al kernel, solo per lasciare lo user space isolato - per esempio, un kernel "realtime" fortemente modificato, e poi X11 per la GUI.
Android è l'opposto: solo cambiamenti minimali al kernel, ma uno user space esclusivo, diversamente da ogni altro sistema Unix. Infatti, lo user space di Android è così differente dal Linux tradizionale, che si può dire che Android non sia un sistema Linux eccetto che per il kernel.
Ecco una lista concisa dei cambiamenti che abbiamo apportato al kernel di Linux:
- ashmem (Android Shared Memory), un sistema di memoria condivisa file-based;
- Binder, un sistema IPC ed RPC;
- logger, un sistema hi-speed interno al kernel di logging ottimizzato per le scritture;
- Paranoid Networking, un meccanismo per ridurre l'I/O di rete a determinati processi;
- pmem, un driver per mappare chunk grandi di memoria fisica nello user space;
- Viking Killer, un OOM killer di rimpiazzo che implementa la logica di Android "killa i processi recenti meno utilizzati" in condizioni di memoria libera scarsa;
- wakelock, la soluzione unica di Android per il power management, per cui lo stato di default del dispositivo è sleep e sono richieste azioni esplicite (via il wakelock) per svegliarlo.
E ovviamente tutto il solito assortimento di driver, port per architetture ARM, e altro codice a basso livello per supportare Android su ogni dispositivo.
Di questa lista, quasi tutti i punti sono stati implementati come driver di dispositivo con modifiche al core del kernel minimali o assenti. L'unico cambiamento significativo è l'implementazione dei wakelock.
Per cui, ecco la risposta: la cosa più invasiva che ha realizzato Google è il meccanismo di wakelock, mentre il resto è tutto farina del sacco di Mountain View che però non interferisce per nulla o quasi col lavoro predefinito del kernel del ramo Linus Torvalds "e figli". Molto molto bene. Non credo di aver mai trovato righe così interessanti su Android e su quale sia il rapporto che lega i due team di development (e i due code stack).
Ringrazio il mio ottimo "collega" Alessio Sergi per la segnalazione.
Photo courtesy of Tom Page