Recentemente abbiamo intervistato eng.stk, lo sviluppatore del kernel blu_spark. In questa parte gli chiediamo delle sue origini e del suo lavoro di sviluppo.
Recentemente ho avuto la possibilità di intervistare il membro senior di XDA eng.stk, sviluppatore del kernel blu_spark. È disponibile su molti dispositivi sui nostri forum, inclusi Nexus 5, OnePlus 3/T e OnePlus 5T. In questa parte chiediamo a eng.stk quali sono le sue origini nello sviluppo e come ha sviluppato il kernel blu_spark.
Quindi, per prima cosa, presenta te stesso e il tuo kernel. In che modo il vostro kernel si differenzia dalla concorrenza? Qual è la tua filosofia di progettazione per le modifiche al kernel e come le procedi?
Sono eng.stk e sono su XDA dal 2010. Molti di voi mi conoscono dai miei progetti code_blue e blu_spark :)
Ho iniziato su XDA scrivendo alcuni script e strumenti vari, hack del framework. Ho anche realizzato molti temi... Durante la mia permanenza qui ho anche collaborato direttamente ad alcuni progetti come Purity ROM, Universal Kernel Manager, Kernel Adiutor e più recentemente Magisk e WireGuard solo per citarne alcuni. Ultimamente ho svolto anche alcuni lavori TWRP (soprattutto sui dispositivi OnePlus), moduli Magisk e altri strumenti/hack [che sono] utili durante il ciclo di vita dei miei progetti kernel (alcune cose sono finite sul portale XDA se ricordo bene correttamente). Il kernel blu_spark ha iniziato a diventare non solo un kernel, ma un'esperienza completa tra kernel, toolchain, ripristino, temi, strumenti, script, ecc. Ma il lavoro sul kernel è ciò che mi piace di più e ciò che mi motiva.
Mi è sempre piaciuto hackerare e costruire codici/script quando ne avevo la possibilità (smontare i giocattoli elettronici e la codifica di base sul Commodore 64 di mio cugino è stato divertente). Per me il coding non è un mezzo per raggiungere un fine ma solo uno strumento come altri per raggiungere uno scopo definito. La maggior parte delle cose più serie e le basi del mio lavoro sono state realizzate quando ho scoperto Linux durante la mia adolescenza, quando avevo vent'anni. Più tardi, da qualche parte durante i tempi dell'università, Android è stato per me il logico passo successivo: davvero il sogno di un armeggiatore, dove l'hardware o il software potevano essere giocati molto.
Le parole migliori per descrivere blu_spark sono ottimizzazione e stabilità. Le persone che lo utilizzano sanno che possono contare su di esso. Le build del mio kernel sono un po' "tozze" in modo che tendo a non rimuovere alcune cose disponibili immediatamente, mantenendo tutto opzionale in modo che le persone possano scegliere. Non mi piace aggiungere troppe cose, semplicemente cambio o aggiungo quello che considero il migliore per ogni dato campo. Il driver della frequenza della CPU, lo scheduler IO, i protocolli di rete, i file system ecc. Oppure modifica alcuni parametri sintonizzabili per alcuni parametri specificati o esegui l'upstream di alcuni driver per il miglior risultato possibile. Costruisco anche toolchain personalizzate (da Linaro, fantastica interpretazione di GCC), principalmente per ottenere il meglio dall'architettura.
In conclusione, la maggior parte delle persone sa di utilizzare blu_spark dal momento in cui esegue il flashing del kernel sul dispositivo. Sono sempre alla ricerca di nuove cose e modi per offrire la migliore UX possibile. In sicurezza.
Raccontaci del tuo governatore blu_active! Cos'è, cosa fa e perché è speciale?
So che le persone a volte confondono blu_active con blu_spark. blu_active è solo una piccola parte rispetto a tutto il resto [del lavoro] che faccio.
Il governatore della CPU prende fondamentalmente decisioni per aumentare o diminuire le frequenze della CPU, in base alle esigenze del sistema. Il governatore ha subito diversi cambiamenti e mutazioni da quando ha iniziato. Come ogni altra cosa che faccio, avevo bisogno di qualcosa che soddisfacesse le mie esigenze. È basato sul mio governatore preferito, il governatore interattivo. All'inizio ci ho messo solo alcune cose a monte, ma poi ho iniziato ad aggiungere altre cose, come gli aggiornamenti CAF o la logica che avevo visto in altri governatori e che trovo utili. Ho anche aggiunto la compatibilità HMP e alcune altre chicche.
L'ultima iterazione è basata sul ramo Android Linux 4.4 di Google, con alcune correzioni upstream e CAF, ma molto più snella di prima. Usa semplicemente ciò che hai al massimo, rimuovi ciò che non hai. Cerco sempre di ottenere una batteria migliore rispetto alle impostazioni di serie, riducendo il consumo e cercando di migliorare performance (performance nella vita reale, quella che senti con gli occhi e le dita, non con i sintetici utensili).
Ad un certo punto, volevo un semplice accordabile in modo che le persone potessero giocare con le prestazioni in modo semplice. Ecco come è nata Fastlane :). La logica è in qualche modo simile al modo in cui funziona Honda VTEC: gioca con i tempi a partire da una determinata soglia. Quindi, con un semplice interruttore e un valore di soglia variabile, le persone potrebbero avere un ridimensionamento della frequenza della CPU più diretto e aggressivo. Facendolo entrare prima o poi in base al carico del sistema, bypassando i carichi target. È completamente compatibile con HMP e può essere ottimizzato per cluster in base alle esigenze delle persone, ottimizzato per ciascun dispositivo su cui viene eseguito.
Quali meccanismi o modifiche integrati ti piacciono/non ti piacciono forniti dagli OEM? ovvero il potenziamento dell'input di Qualcomm.
Alcuni potenziamenti dello spazio utente e altri parametri sintonizzabili impostati negli HAL (Hardware Abstraction Layers), elementi del framework hardcoded ecc., a volte possono essere fastidiosi. Naturalmente, gli sviluppatori del kernel sono noti per aggirare alcuni di questi problemi. Sul Nexus 5, ad esempio, la maggior parte di noi si è sbarazzata di mpdecision e ha ottenuto un hotplug personalizzato: all'epoca avevamo blu_plug installato. Alcuni altri dispositivi avevano una cattiva gestione termica e un controllo termico personalizzato con sysfs per livelli di temperatura, frequenza di mitigazione ecc. Alcuni dispositivi più recenti hanno alcune politiche rigide sulla batteria, sullo scollegamento dei core e altre cose a "livelli bassi" che non hanno apportato un reale guadagno nell'utilizzo del dispositivo. È un dato di fatto, a volte rovinava persino l'esperienza dell'utente, quindi era necessario domare le tecnologie CTL e BCL.
Ricordo anche di aver rimosso la crittografia nei dispositivi quando questa era una cosa, tutte le modifiche che le iterazioni di SELinux hanno introdotto modifiche che hanno fatto sì che gli hack precedenti funzionassero in un modo diverso... alcune recenti modifiche alla sicurezza di Android rappresentano una sfida costante. Questi includono AVB (alcune parti conosciute principalmente come dm-verity). Alcune altre modifiche hanno introdotto restrizioni per i parametri sintonizzabili e i luoghi sysfs che hanno dovuto essere spostati perché non abbiamo accesso agli stessi posti che avevamo prima. La maggior parte di queste restrizioni sono più rilevanti per le ROM stock (nelle quali svolgo la maggior parte del mio lavoro), normalmente aprono la strada e rendono più semplice il processo quando si tratta di ROM personalizzate (dove le restrizioni sono inferiori).
Nei SoC recenti come Qualcomm Snapdragon 820 e 835, alcuni OEM hanno aggiunto alcuni miglioramenti dallo spazio utente che sono benvenuti e risolvono i punti ciechi del sistema, non tutte le cose OEM sono negative. Quando si tratta del codice sorgente del kernel, più il codice è pulito e documentato, meglio è.
Quali altre funzionalità ti piacerebbe includere? Come il controllo avanzato del colore e così via.
Normalmente non includo cose che non uso personalmente o che non trovo utili. Le cose che mi piace fare, oltre a blu_active, includono ottimizzazioni e correzioni dell'architettura, aggiornamenti di cose crittografiche, pianificazione IO e altro gadget di archiviazione/file system, KCAL, ricarica rapida USB, intensità di vibrazione, controllo LED batteria/notifica, blocchi Wakelock, WireGuard, eccetera. Costruisco sempre con una toolchain di creazione personalizzata come ho detto prima.
Quale metodologia di test usi per il tuo kernel? Utilizzi report utente, benchmark o altre routine personalizzate?
Possiedo tutti i telefoni per cui sviluppo, quindi qualsiasi modifica viene sempre testata da me. Dal momento che utilizzo quotidianamente qualsiasi dispositivo per un lungo periodo di tempo, tutto ciò che trovo non adatto a me, non dovrebbe essere adatto a nessun altro. Quando rilascio pubblicamente una build, questa ha già ricevuto molti test da parte mia e di altre persone di cui mi fido per fornire feedback utili. So che a volte alcuni utenti si annoiano perché tutto funziona come dovrebbe, ma per me è importante soprattutto la stabilità: mi metto sempre nei panni dell'utente in primo luogo.
Eseguo le cose verso un caso d'uso nella vita reale, non verso test sintetici. Questo tipo di software è fatto per gli esseri umani, non per le macchine di un back office. Il punto di partenza è sempre migliore dell'esperienza stock, su tutti i fronti, ma non apprezzo molto l'ultimo punteggio elevato di Antutu. I miei kernel possono essere adattati a questo tipo di benchmark, ma non è il mio obiettivo finale. Apprezzo alcuni benchmark più diretti, come ad esempio i test sullo storage IO. Possono fornire un modo rapido per affermare alcune modifiche apportate di recente, ad esempio.
Eseguo i test con ROM stock in modo da poter avere una base stabile per le cose. Eseguo build personalizzate per ROM personalizzate, ma a causa della natura volatile delle ROM personalizzate con extra aggiunti, nightlies e persino differenza di implementazione su alcune funzionalità, è impossibile coprirle tutte e fornire il supporto adeguato a tutti, Purtroppo.
A volte creo anche build beta per testare qualcosa di specifico o per quando lancio build su ROM Beta o anteprime per sviluppatori. L'ho fatto sui dispositivi Nexus e OnePlus, alle persone a volte piace testare le cose :)
Dai un'occhiata alla parte 2: F2FS, EAS e suggerimenti per aspiranti sviluppatori di kernel