Vi intervjuet nylig eng.stk, utvikleren av blu_spark-kjernen. I denne delen spør vi ham om hans opphav og utviklingsarbeid.
Jeg fikk nylig sjansen til å intervjue XDA Senior Member eng.stk, utvikler av blu_spark-kjernen. Den er tilgjengelig på mange enheter på forumene våre, inkludert Nexus 5, OnePlus 3/T og OnePlus 5T. I denne delen spør vi eng.stk om hans opprinnelse til utvikling og hvordan han utvikler blu_spark-kjernen.
Så først, introduser deg selv og kjernen din. Hvordan skiller kjernen seg fra konkurrentene? Hva er designfilosofien din for kjerneendringer, og hvordan går du frem?
Jeg er eng.stk og har vært rundt på XDA siden 2010. De fleste av dere kjenner meg fra prosjektene mine code_blue og blu_spark :)
Jeg startet på XDA med å skrive noen skript og diverse verktøy, rammeverkshack. Jeg har også laget mange temaer... I løpet av min tid her har jeg også direkte samarbeidet med noen prosjekter som Purity ROM, Universal Kernel Manager, Kernel Adiutor og mer nylig Magisk og WireGuard bare for å nevne noen få. Jeg har også gjort noe TWRP-arbeid i det siste (spesielt på OnePlus-enheter), Magisk-moduler og andre verktøy/hacks [som er] nyttige i løpet av livssyklusen til kjerneprosjektene mine (noen ting gikk på XDA-portalen hvis jeg husker riktig). blu_spark-kjernen begynte å bli ikke bare en kjerne, men en allsidig opplevelse mellom kjerne, verktøykjeder, gjenoppretting, tema, verktøy, skript, etc. Men kjernearbeid er det jeg liker best og det som driver meg.
Jeg har alltid likt å hacke rundt og bygge litt kode/skript når jeg hadde sjansen (det var gøy å demontere elektroniske leker og grunnleggende koding på min fetters Commodore 64). For meg er koding ikke et middel til et mål, men bare et verktøy som noen andre for å oppnå et definert formål. De fleste av mine mer seriøse ting og grunnlaget for arbeidet mitt ble gjort da jeg oppdaget Linux i ungdomsårene/tidlige tjueårene. Senere, et sted under universitetstiden, var Android det logiske neste skrittet for meg: en tinderdrøm egentlig, hvor maskinvare eller programvare kunne lekes med mye.
De beste ordene for å beskrive blu_spark er optimalisering og stabilitet. Folk som bruker det vet at de kan stole på det. Kjernebyggene mine er noe "stockish" på en måte som gjør at jeg ikke har en tendens til å fjerne noe tilgjengelig fra esken, og holder alt valgfritt slik at folk kan velge. Jeg liker ikke å legge til for mye ting, jeg bare endrer eller legger til det jeg anser som best for hvert gitt felt. CPU freq-driveren, IO-planleggeren, nettverksprotokollene, filsystemene osv. eller finjuster noen tunables for noen gitte parametere eller oppstrøms noen drivere for best mulig resultat. Jeg bygger også skreddersydde verktøykjeder (fra Linaro, fantastisk versjon av GCC), hovedsakelig for å få det beste ut av arkitekturen.
Bunnlinjen, de fleste vet at de er på blu_spark fra det øyeblikket de flasher kjernen på enheten. Jeg er alltid på utkikk etter nye ting og måter å gi best mulig UX. Trygt.
Fortell oss om din blu_active-guvernør! Hva er det, hva gjør det og hvorfor er det spesielt?
Jeg vet at folk noen ganger forveksler blu_active med blu_spark. blu_active er bare en liten del sammenlignet med alt det andre [av arbeidet] jeg gjør.
CPU-guvernøren tar i utgangspunktet beslutninger om å få CPU-frekvensene til å gå opp eller ned, i henhold til systemets behov. Sysselmannen har hatt flere endringer og mutasjoner siden det startet. Som alt annet jeg gjør, trengte jeg noe som dekket mine behov. Den er basert på favorittguvernøren min, den interaktive guvernøren. I begynnelsen la jeg bare noen oppstrøms ting på den, men så begynte jeg å legge til noen andre ting, som CAF-oppdateringer eller logikk jeg hadde sett i andre guvernører som jeg finner nyttige. Jeg har også lagt til HMP-kompatibilitet og noen andre godbiter.
Den siste iterasjonen er basert på Googles Linux 4.4 Android-gren, med noen oppstrøms- og CAF-reparasjoner også, men mye slankere enn før. Bare bruk det du har til det fulle, fjern det du ikke har. Jeg prøver alltid å få et bedre batteri enn med lagerinnstillinger, reduserer drenering, mens jeg prøver å forbedre ytelse (prestasjon i det virkelige liv, den du føler med øynene og fingrene, ikke med syntetisk verktøy).
På et tidspunkt ønsket jeg en enkel tunbar slik at folk kunne leke med ytelse på en enkel måte. Slik ble Fastlane født :). Logikken er litt lik måten Honda VTEC fungerer på: lek med timing fra en gitt terskel. Så, med en enkel bryter og en variabel terskelverdi, kan folk ha en mer direkte og aggressiv cpu-frekvensskalering. Få den til å gå inn før eller siden i henhold til systembelastningen, og omgå målbelastninger. Den er fullt kompatibel med HMP og kan justeres per klynge i henhold til folks behov, finjustert for hver enhet den kjører på.
Hvilke innebygde mekanismer eller justeringer liker du/misliker du som OEM-er tilbyr? dvs. Qualcomms input boost.
Noen brukerplassforsterkninger og andre tunables som er satt i HALs (Hardware Abstraction Layers), hardkodede rammeverk etc, kan noen ganger være irriterende. Selvfølgelig er kjerneutviklere kjent for å omgå noen av disse. På Nexus 5, for eksempel, ble de fleste av oss kvitt mpdecision og fikk en tilpasset hotplug - vi hadde blu_plug på plass på den tiden. Noen andre enheter hadde dårlig termisk styring og en tilpasset termisk kontroll med sysfs for temperaturnivåer, avbøtende frekvens osv. Noen nyere enheter har noen harde retningslinjer for batteri, frakobling av kjerner og andre ting i "lave nivåer" som ikke ga en reell gevinst i enhetsbruken. Faktisk ødela det til og med brukeropplevelsen noen ganger, så det var nødvendig å temme ned CTL- og BCL-teknologiene.
Jeg husker også at jeg fjernet kryptering i enheter når det var en ting, alle endringene SELinux-iterasjoner introduserte endringer som gjorde at tidligere hacks fungerte på en annen måte... noen nylige Android-sikkerhetsendringer er en konstant utfordring. Disse inkluderer AVB (noen deler mest kjent som dm-verity). Noen andre endringer har gjort restriksjoner for tunables og sysfs-plasser som måtte flyttes fordi vi ikke har tilgang til de samme stedene vi hadde før. De fleste av disse restriksjonene er mer relevante for lager-ROM-er (der jeg gjør mesteparten av arbeidet mitt), normalt baner det veien og gjør det lettere når det kommer til tilpassede ROM-er (der restriksjonene er lavere).
I nyere SoC-er som Qualcomm Snapdragon 820 og 835 har noen OEM-er lagt til noen løft fra brukerområdet som er velkomne og takler blindsoner i systemet, ikke alle OEM-ting er dårlige. Når det kommer til kjernekilde, jo renere og mer dokumentert kilden er, jo bedre.
Hvilke andre funksjoner liker du å inkludere? Slik som avansert fargekontroll og så videre.
Jeg inkluderer vanligvis ikke ting jeg ikke bruker personlig eller som jeg ikke finner det nyttig. Ting jeg liker å gjøre, foruten blu_active, inkluderer arkitekturoptimaliseringer og rettelser, oppdateringer av kryptoting, IO-planlegging og annet lagrings-/filsystemgodbiter, KCAL, USB hurtiglading, vibrasjonsstyrke, batteri/varslings LED-kontroll, Wakelock-blokkere, WireGuard, etc. Jeg bygger alltid med en tilpasset verktøykjede som jeg sa tidligere.
Hvilken testmetodikk bruker du for kjernen din? Bruker du brukerrapporter, benchmarks eller andre tilpassede rutiner?
Jeg eier alle telefonene jeg utvikler for, så eventuelle endringer testes alltid av meg selv. Siden jeg daglig kjører hver enhet i en lang periode, bør ikke alt jeg finner ikke passe for meg, passe for noen andre. Når jeg offentliggjør en build, har den allerede hatt mange tester fra meg og noen andre som jeg stoler på for å gi nyttig tilbakemelding. Jeg vet at noen brukere noen ganger blir lei av å hele tiden ha alt som fungerer som det skal, men jeg verdsetter stabilitet fremfor alt: Jeg setter meg alltid på en brukers sko i utgangspunktet.
Jeg kjører ting mot en virkelig brukssak, ikke syntetiske tester. Denne typen programvare er laget for mennesker, ikke maskiner i et backoffice. Utgangspunktet er alltid bedre enn aksjeerfaring, på alle fronter, men jeg verdsetter ikke den siste Antutu-høyscore så mye. Kjernene mine kan stilles inn til denne typen benchmark, men det er ikke mitt sluttmål. Jeg verdsetter noen benchmarks som er mer direkte, som IO-lagringstesting for eksempel. De kan gi en rask måte å hevde noen endringer nylig gjort for eksempel.
Jeg tester med lager-ROM-er slik at jeg kan ha en stabil baseline for ting. Jeg lager tilpassede bygg for tilpassede ROM-er, men på grunn av flyktige natur til tilpassede ROM-er med ekstrautstyr, nattblader og til og med implementeringsforskjell på enkelte funksjoner, det er umulig å dekke dem alle og gi riktig støtte til alle, dessverre.
Noen ganger bygger jeg også beta-bygg for å teste noe spesifikt eller for når jeg lanserer bygg til beta-ROM-er eller forhåndsvisninger av utviklere. Jeg gjorde det på Nexus- og OnePlus-enhetene, folk liker å teste ut ting noen ganger :)
Sjekk ut del 2: F2FS, EAS og tips for aspirerende kjerneutviklere