Vi intervjuade nyligen eng.stk, utvecklaren av blu_spark-kärnan. I denna del frågar vi honom om hans ursprung och utvecklingsarbete.
Jag fick nyligen chansen att intervjua XDA Senior Member eng.stk, utvecklare av blu_spark-kärnan. Den är tillgänglig på många enheter på våra forum, inklusive Nexus 5, OnePlus 3/T och OnePlus 5T. I den här delen frågar vi eng.stk om hans ursprung i utvecklingen och hur han utvecklar blu_spark-kärnan.
Så först, presentera dig själv och din kärna. Hur skiljer sig din kärna från konkurrenterna? Vad är din designfilosofi för kärnförändringar och hur går du tillväga?
Jag är eng.stk och jag har funnits på XDA sedan 2010. De flesta av er känner mig från mina code_blue och blu_spark-projekt :)
Jag började på XDA med att skriva några skript och diverse verktyg, ramverkshack. Jag har gjort många tema också... Under min tid här har jag också direkt samarbetat med några projekt som Purity ROM, Universal Kernel Manager, Kernel Adiutor och på senare tid Magisk och WireGuard bara för att nämna några. Jag har också gjort en del TWRP-arbete på sistone (särskilt på OnePlus-enheter), Magisk-moduler och andra verktyg/hack [som är] användbara under livscykeln för mina kärnprojekt (vissa saker gick på XDA-portalen om jag minns korrekt). blu_spark-kärnan började bli inte bara en kärna, utan en allsidig upplevelse mellan kärna, verktygskedjor, återställning, teman, verktyg, skript, etc. Men kärnarbete är det jag trivs bäst med och som driver mig.
Jag har alltid tyckt om att hacka runt och bygga lite kod/skript när jag hade chansen (att demontera elektroniska leksaker och grundläggande kodning på min kusins Commodore 64 var kul). För mig är kodning inte ett medel till ett mål utan bara ett verktyg som vissa andra för att uppnå ett definierat syfte. De flesta av mina mer seriösa saker och grunderna för mitt arbete gjordes när jag upptäckte Linux under min tonårstid/tidiga tjugoårsåldern. Senare, någonstans under universitetstiden, var Android det logiska nästa steget för mig: en pysslingsdröm egentligen, där hårdvara eller mjukvara kunde lekas med mycket.
De bästa orden för att beskriva blu_spark är optimering och stabilitet. Människor som använder det vet att de kan lita på det. Mina kärnkonstruktioner är något "stockish" på ett sätt som jag tenderar att inte ta bort vissa saker som finns tillgängliga ur lådan, hålla allt valfritt så att folk kan välja. Jag gillar inte att lägga till för mycket grejer, jag ändrar eller lägger bara till det jag anser är bäst för varje givet fält. CPU freq-drivrutinen, IO-schemaläggaren, nätverksprotokollen, filsystemen etc eller justera några tunables för vissa givna parametrar eller uppströms några drivrutiner för bästa möjliga resultat. Jag bygger också skräddarsydda verktygskedjor (från Linaro, fantastisk version av GCC), främst för att få ut det bästa av arkitekturen.
Sammanfattningsvis vet de flesta att de är på blu_spark från det ögonblick de flashar kärnan på enheten. Jag letar alltid efter nya saker och sätt att ge bästa möjliga UX. Säkert.
Berätta för oss om din blu_active-guvernör! Vad är det, vad gör det och varför är det speciellt?
Jag vet att folk ibland blandar ihop blu_active med blu_spark. blu_active är bara en liten del jämfört med allt annat [av arbetet] som jag gör.
CPU-regulatorn fattar i princip beslut om att få CPU-frekvenserna att gå upp eller ner, beroende på systemets behov. Guvernören har haft flera förändringar och mutationer sedan det startade. Som allt annat jag gör behövde jag något som uppfyllde mina behov. Den är baserad på min favoritguvernör, den interaktiva guvernören. I början satte jag bara några uppströms saker på den, men sedan började jag lägga till några andra saker, som CAF-uppdateringar eller logik som jag hade sett i andra guvernörer som jag tycker är användbara. Jag lade också till HMP-kompatibilitet och några andra godsaker.
Den senaste iterationen är baserad på Googles Linux 4.4 Android-gren, med några uppströms- och CAF-fixar också, men mycket slankare än tidigare. Använd helt enkelt det du har till fullo, ta bort det du inte har. Jag försöker alltid få bättre batteri än med lagerinställningar, vilket minskar dräneringen samtidigt som jag försöker förbättra prestanda (prestandan i verkligheten, den som du känner med dina ögon och fingrar, inte med syntetiska verktyg).
Vid ett tillfälle ville jag ha en enkel avstämbar så att folk kunde leka med prestanda på ett enkelt sätt. Så här föddes Fastlane :). Logiken påminner något om hur Honda VTEC fungerar: lek med timings från en given tröskel. Så, med en enkel switch och ett variabelt tröskelvärde, skulle människor kunna ha en mer direkt och aggressiv cpu-frekvensskalning. Att få den att komma in förr eller senare enligt systembelastningen, förbi målbelastningar. Den är helt kompatibel med HMP och kan justeras per kluster efter människors behov, finjusteras för varje enhet den körs på.
Vilka inbyggda mekanismer eller tweaks gillar/ogillar du som OEM-tillverkare tillhandahåller? dvs Qualcomms input boost.
Vissa användarutrymmesförstärkningar och andra justeringar som är inställda i HALs (Hardware Abstraction Layers), hårdkodade ramverk etc, kan ibland vara irriterande. Naturligtvis är kärnutvecklare kända för att kringgå några av dessa. På Nexus 5, till exempel, blev de flesta av oss av med mpdecision och fick en anpassad hotplug - vi hade blu_plug på plats vid den tiden. Vissa andra enheter hade dålig termisk hantering och en anpassad termisk kontroll med sysfs för temperaturnivåer, dämpningsfrekvens etc. Vissa nyare enheter har vissa hårda policyer för batteri, urkoppling av kärnor och andra saker i "låga nivåer" som inte gjorde en verklig vinst i enhetsanvändningen. Faktum är att det till och med förstörde användarupplevelsen ibland, så det var nödvändigt att tämja ner CTL- och BCL-teknikerna.
Jag minns också att jag tog bort kryptering i enheter när det var en grej, alla ändringar som SELinux-iterationer introducerade ändringar som gjorde att tidigare hack fungerade på ett annat sätt... vissa senaste Android-säkerhetsförändringar är en ständig utmaning. Dessa inkluderar AVB (vissa delar kallas oftast dm-verity). Vissa andra ändringar har gjort restriktioner för tunables och sysfs-platser som måste flyttas eftersom vi inte har tillgång till samma platser som vi hade tidigare. De flesta av dessa begränsningar är mer relevanta för lager-ROM (där jag gör det mesta av mitt arbete), normalt banar det vägen och gör det lättare när det kommer till anpassade ROM-skivor (där restriktionerna är lägre).
Under de senaste SoCs som Qualcomm Snapdragon 820 och 835, har vissa OEM-tillverkare lagt till några boosts från användarutrymmet som är välkomna och tacklar blinda fläckar i systemet, inte alla OEM-grejer är dåliga. När det kommer till kärnkällan, ju renare och mer dokumenterad källan är, desto bättre.
Vilka andra funktioner vill du ha med? Som avancerad färgkontroll och så vidare.
Jag inkluderar vanligtvis inte saker som jag inte personligen använder eller som jag inte tycker är användbara. Saker jag gillar att göra, förutom blu_active, inkluderar arkitekturoptimeringar och fixar, uppdateringar av kryptogrejer, IO-schemaläggning och annat lagrings-/filsystemgodis, KCAL, USB-snabbladdning, vibrationsstyrka, batteri/aviserings-LED-kontroll, Wakelock-blockerare, WireGuard, etc. Jag bygger alltid med en specialbyggd verktygskedja som jag sa tidigare.
Vilken testmetod använder du för din kärna? Använder du användarrapporter, benchmarks eller andra anpassade rutiner?
Jag äger alla telefoner som jag utvecklar för, så alla förändringar testas alltid av mig. Eftersom jag dagligen kör varje enhet under en lång tidsperiod bör allt jag inte tycker passar mig, inte vara lämpligt för någon annan. När jag släpper en build offentligt har den redan testats massor av mig och några andra personer som jag litar på för att ge användbar feedback. Jag vet att vissa användare ibland blir uttråkade av att ständigt ha alla saker som fungerar som de ska, men jag värdesätter stabilitet framför allt: jag sätter mig alltid på en användares skor i första hand.
Jag kör saker mot ett verkligt användningsfall, inte syntetiska tester. Den här typen av programvara är gjord för människor, inte maskiner i ett backoffice. Utgångspunkten är alltid bättre än aktieerfarenhet, på alla fronter, men jag värderar egentligen inte den senaste Antutu-högpoängen så mycket. Mina kärnor kan ställas in på den här typen av benchmark, men det är inte mitt slutmål. Jag värdesätter vissa riktmärken som är mer direkta, som IO-lagringstestning till exempel. De kan ge ett snabbt sätt att hävda vissa nyligen gjorda förändringar till exempel.
Jag gör mina tester med lager-ROM så att jag kan ha en stabil baslinje för saker och ting. Jag gör skräddarsydda konstruktioner för anpassade ROM-skivor, men på grund av flyktiga egenskaper hos anpassade ROM-skivor med extra tillbehör, nattblad och till och med implementeringsskillnad på vissa funktioner, det är omöjligt att täcka dem alla och ge korrekt support till alla, tyvärr.
Jag bygger också ibland betaversioner för att testa något specifikt eller för när jag lanserar builds till beta-ROM eller utvecklare förhandsvisningar. Jag gjorde det på Nexus- och OnePlus-enheterna, folk gillar att testa saker ibland :)
Kolla in del 2: F2FS, EAS och tips för blivande kärnutvecklare