Vi har for nylig interviewet eng.stk, udvikleren af blu_spark-kernen. I denne del spørger vi ham om hans oprindelse og udviklingsarbejde.
Jeg fik for nylig chancen for at interviewe XDA Senior Member eng.stk, udvikler af blu_spark-kernen. Den er tilgængelig på mange enheder på vores fora, inklusive Nexus 5, OnePlus 3/T og OnePlus 5T. I denne del spørger vi eng.stk om hans oprindelse i udvikling og hvordan han udvikler blu_spark kernen.
Så først præsentere dig selv og din kerne. Hvordan adskiller din kerne sig fra konkurrenterne? Hvad er din designfilosofi for kerneændringer, og hvordan griber du dem an?
Jeg er eng.stk, og jeg har været rundt på XDA siden 2010. De fleste af jer kender mig fra mine code_blue og blu_spark projekter :)
Jeg startede på XDA ved at skrive nogle scripts og diverse værktøjer, framework hacks. Jeg har også lavet en masse temaer... I løbet af min tid her har jeg også direkte samarbejdet om nogle projekter som Purity ROM, Universal Kernel Manager, Kernel Adiutor og for nylig Magisk og WireGuard bare for at nævne nogle få. Jeg har også lavet noget TWRP-arbejde på det seneste (især på OnePlus-enheder), Magisk-moduler og andre værktøjer/hacks [der er] nyttige under livscyklussen af mine kerneprojekter (nogle ting gik på XDA-portalen, hvis jeg husker det korrekt). blu_spark-kernen begyndte ikke kun at blive en kerne, men en alsidig oplevelse mellem kerne, værktøjskæder, gendannelse, tematisering, værktøjer, scripts osv. Men kernearbejde er det, jeg nyder mest, og det, der driver mig.
Jeg har altid nydt at hacke rundt og bygge nogle kode/scripts, når jeg havde chancen (det var sjovt at skille elektronisk legetøj ad og grundlæggende kodning på min fætters Commodore 64). For mig er kodning ikke et middel til et mål, men blot et værktøj som nogle andre til at opnå et defineret formål. De fleste af mine mere seriøse ting og grundlaget for mit arbejde blev gjort, da jeg opdagede Linux i min teenageår/begyndelse af tyverne. Senere, et eller andet sted i universitetets tid, var Android det logiske næste skridt for mig: virkelig en tømmermands drøm, hvor der kunne leges meget med hardware eller software.
De bedste ord til at beskrive blu_spark er optimering og stabilitet. Folk, der bruger det, ved, at de kan stole på det. Mine kernebygninger er noget "stockish" på en måde, så jeg har en tendens til ikke at fjerne nogle tilgængelige ting ud af kassen, og holder alt valgfrit, så folk kan vælge. Jeg kan ikke lide at tilføje for mange ting, jeg ændrer eller tilføjer bare, hvad jeg anser for det bedste for hvert givent felt. CPU freq-driveren, IO-planlæggeren, netværksprotokollerne, filsystemerne osv. eller tweak nogle tunables for nogle givne parametre eller upstream nogle drivere for det bedst mulige resultat. Jeg bygger også specialfremstillede værktøjskæder (fra Linaro, fantastisk version af GCC), primært for at få det bedste ud af arkitekturen.
Bundlinjen ved de fleste, at de er på blu_spark fra det øjeblik, de flasher kernen på enheden. Jeg leder altid efter nye ting og måder at give den bedst mulige UX. Sikkert.
Fortæl os om din blu_active guvernør! Hvad er det, hvad gør det, og hvorfor er det specielt?
Jeg ved, at folk nogle gange forveksler blu_active med blu_spark. blu_active er kun en lille del sammenlignet med alt det øvrige [af det arbejde], jeg laver.
CPU-guvernøren træffer grundlæggende beslutninger om at få CPU-frekvenserne til at gå op eller ned, alt efter systemets behov. Guvernøren har haft flere ændringer og mutationer siden det startede. Som alt andet, jeg laver, havde jeg brug for noget, der opfyldte mine behov. Det er baseret på min yndlingsguvernør, den interaktive guvernør. I begyndelsen lagde jeg bare noget upstream-ting på det, men så begyndte jeg at tilføje nogle andre ting, såsom CAF-opdateringer eller logik, jeg havde set i andre guvernører, som jeg finder nyttige. Jeg tilføjede også HMP-kompatibilitet og nogle andre godbidder.
Den seneste iteration er baseret på Googles Linux 4.4 Android-gren, med nogle upstream- og CAF-rettelser også, men meget mere slankere end før. Du skal blot bruge det du har fuldt ud, fjerne det du ikke har. Jeg forsøger altid at få et bedre batteri end med lagerindstillinger, hvilket reducerer forbruget, mens jeg prøver at forbedre præstation (virkelig præstation, den du føler med dine øjne og fingre, ikke med syntetisk værktøjer).
På et tidspunkt ville jeg have en enkel tunbar, så folk kunne lege med ydeevnen på en enkel måde. Sådan blev Fastlane født :). Logikken minder lidt om den måde, Honda VTEC fungerer på: leg med timings fra en given tærskel. Så med en simpel switch og en variabel tærskelværdi kunne folk have en mere direkte og aggressiv cpu-frekvensskalering. At få det til at komme ind før eller siden i henhold til systembelastningen, omgå målbelastninger. Den er fuldt ud kompatibel med HMP og kan tilpasses pr. klynge efter folks behov, finjusteret til hver enhed, den kører på.
Hvilke indbyggede mekanismer eller tweaks kan du lide/ikke lide, som OEM'er tilbyder? dvs. Qualcomms input boost.
Nogle userspace boosts og andre tunables, der er indstillet i HAL'er (Hardware Abstraction Layers), hardcodede framework-ting osv., kan nogle gange være irriterende. Selvfølgelig er kerneudviklere kendt for at omgå nogle af dem. På Nexus 5, for eksempel, slap de fleste af os af med mpdecision og fik en brugerdefineret hotplug - vi havde blu_plug på plads på det tidspunkt. Nogle andre enheder havde dårlig termisk styring og en brugerdefineret termisk kontrol med sysf'er til temperaturniveauer, dæmpningsfrekvens osv. Nogle nyere enheder har nogle hårde politikker for batteri, frakobling af kerner og andre ting i "lave niveauer", som ikke gav en reel gevinst i enhedsbrug. Faktisk ødelagde det endda nogle gange brugeroplevelsen, så det var nødvendigt at tæmme CTL- og BCL-teknologierne.
Jeg kan også huske, at jeg fjernede kryptering i enheder, da det var en ting, alle de ændringer, SELinux-iterationer introducerede ændringer, der fik tidligere hacks til at fungere på en anden måde... nogle nylige Android-sikkerhedsændringer er en konstant udfordring. Disse omfatter AVB (nogle dele kendes for det meste som dm-verity). Nogle andre ændringer har lavet restriktioner for tunables og sysfs-steder, der skulle flyttes, fordi vi ikke har adgang til de samme steder, som vi havde før. De fleste af disse begrænsninger er mere relevante for lager-ROM'er (hvor jeg udfører det meste af mit arbejde), normalt baner det vejen og gør det lettere, når det kommer til brugerdefinerede ROM'er (hvor begrænsningerne er lavere).
I de seneste SoC'er som Qualcomm Snapdragon 820 og 835 har nogle OEM'er tilføjet nogle boosts fra brugerområdet, som er velkomne og tackler blinde vinkler i systemet, ikke alle OEM-ting er dårlige. Når det kommer til kernel source, jo renere og mere dokumenteret kilden er, jo bedre.
Hvilke andre funktioner kan du lide at inkludere? Såsom avanceret farvekontrol og så videre.
Jeg medtager normalt ikke ting, som jeg ikke personligt bruger, eller som jeg ikke finder det nyttige. Ting jeg kan lide at lave, udover blu_active, inkluderer arkitekturoptimeringer og rettelser, opdateringer af kryptoting, IO-planlægning og andet lagrings-/filsystemgodter, KCAL, USB-hurtigopladning, vibrationsstyrke, batteri/meddelelses-LED-kontrol, Wakelock-blokkere, WireGuard, etc. Jeg bygger altid med en specialbygget værktøjskæde, som jeg sagde tidligere.
Hvilken testmetode bruger du til din kerne? Bruger du brugerrapporter, benchmarks eller andre tilpassede rutiner?
Jeg ejer alle telefoner, som jeg udvikler til, så alle ændringer testes altid, være mig. Da jeg dagligt kører hver enhed i en længere periode, burde alt, hvad jeg finder ikke egnet til mig, ikke være egnet for nogen andre. Når jeg offentligt udgiver en build, har den allerede haft en masse test fra mig og nogle andre mennesker, som jeg stoler på for at give nyttig feedback. Jeg ved, at nogle brugere nogle gange keder sig af konstant at have alle tingene til at fungere, som de skal, men jeg værdsætter først og fremmest stabilitet: Jeg sætter mig altid på en brugers sko i første omgang.
Jeg kører tingene i retning af en real life use case, ikke syntetiske tests. Denne form for software er lavet til mennesker, ikke maskiner i et backoffice. Udgangspunktet er altid bedre end aktieerfaring på alle fronter, men jeg værdsætter egentlig ikke den seneste Antutu high-score så meget. Mine kerner kan indstilles til denne type benchmark, men det er ikke mit slutmål. Jeg værdsætter nogle benchmarks, der er mere direkte, som IO-lagringstest for eksempel. De kan give en hurtig måde at hævde nogle ændringer, der er foretaget for nylig.
Jeg tester med lager-ROM'er, så jeg kan have en stabil baseline for tingene. Jeg laver brugerdefinerede builds til brugerdefinerede ROM'er, men på grund af den flygtige karakter af brugerdefinerede ROM'er med ekstra ekstramateriale, natteblade og endda implementeringsforskel på nogle funktioner, det er umuligt at dække dem alle og give ordentlig support til alle, desværre.
Jeg bygger også nogle gange beta-builds for at teste noget specifikt, eller når jeg lancerer builds til beta-ROM'er eller udviklerforhåndsvisninger. Jeg gjorde det på Nexus- og OnePlus-enhederne, folk kan lide at teste ting nogle gange :)
Se del 2: F2FS, EAS og tips til håbefulde kerneudviklere