Intervjuu arendajaga eng.stk 1. osa: päritolu ja tuuma arendus

Hiljuti intervjueerisime blu_spark tuuma arendajat eng.stk. Selles osas küsime temalt tema päritolu ja arendustöö kohta.

Mul oli hiljuti võimalus intervjueerida XDA vanem liiget eng.stk, blu_spark tuuma arendaja. See on meie foorumites saadaval paljudes seadmetes, sealhulgas Nexus 5, OnePlus 3/T ja OnePlus 5T. Selles osas küsime eng.stk-lt tema arenduse päritolu ja selle kohta, kuidas ta blu_spark tuuma arendab.


Nii et kõigepealt tutvustage ennast ja oma tuuma. Kuidas teie kernel konkurentidest eristub? Milline on teie kerneli muudatuste kujundamise filosoofia ja kuidas te neid teete?

Olen eng.stk ja olen XDA-s olnud alates 2010. aastast. Enamik teist teavad mind minu code_blue ja blu_spark projektidest :)

Alustasin XDA-ga, kirjutades mõned skriptid ja mitmesugused tööriistad, raamistiku häkkimised. Olen ka palju teemasid teinud... Siin veedetud aja jooksul olen teinud ka otsest koostööd mõne projektiga nagu Purity ROM, Universal Kernel Manager, Kernel Adiutor ja viimasel ajal Magisk ja WireGuard
kui nimetada vaid mõnda. Olen viimasel ajal teinud ka TWRP-tööd (eriti OnePlusi seadmetes), Magiski mooduleid ja muid tööriistu/häkkisid [mis on] kasulikud minu kerneliprojektide elutsükli jooksul (mõned asjad läksid XDA portaali, kui ma mäletan õigesti). blu_spark kernelist ei saanud mitte ainult kernel, vaid ka kõikehõlmav kogemus kerneli, tööriistaahelate, taastamise, teemastamise, tööriistade, skriptide jne vahel. Kuid tuumatöö on see, mida ma kõige rohkem naudin ja mis mind juhib.

Nautisin alati häkkimist ja koodi/skriptide koostamist, kui mul võimalus oli (elektrooniliste mänguasjade lahtivõtmine ja põhiline kodeerimine mu nõbu Commodore 64-l oli lõbus). Minu jaoks ei ole kodeerimine vahend eesmärgi saavutamiseks, vaid lihtsalt tööriist nagu mõned teised määratletud eesmärgi saavutamiseks. Suurem osa minu tõsisematest asjadest ja töö alustest sai tehtud siis, kui avastasin noorukieas/kahekümnendate alguses Linuxi. Hiljem, kuskil ülikooliajal, oli Android minu jaoks loogiline järgmine samm: nokitseja unistus tõesti, kus riist- või tarkvaraga sai palju mängida.

Parimad sõnad blu_sparki kirjeldamiseks on optimeerimine ja stabiilsus. Inimesed, kes seda kasutavad, teavad, et saavad sellele loota. Minu kerneli järgud on mõnevõrra „tootvad”, nii et ma ei võta osa saadaolevaid asju karbist välja, jättes kõik valikuliseks, et inimesed saaksid valida. Mulle ei meeldi liiga palju asju lisada, ma lihtsalt muudan või lisan seda, mida pean iga valdkonna jaoks parimaks. Protsessori sagedusdraiver, IO-planeerija, võrguprotokollid, failisüsteemid jne või kohandage teatud parameetrite jaoks mõnda häälestatavat seadet või parima võimaliku tulemuse saavutamiseks mõnda draiverit ülesvoolu. Ehitan ka eritellimusel valmistatud tööriistakette (Linarost, vinge GCC vastuvõtt), peamiselt selleks, et saada arhitektuurist parim.

Kokkuvõtteks võib öelda, et enamik inimesi teab, et nad on rakenduses blu_spark alates hetkest, kui nad seadmes kerneli välgutavad. Otsin alati uusi asju ja viise, kuidas pakkuda parimat võimalikku kasutuskogemust. Turvaliselt.

Rääkige meile oma blu_active kubernerist! Mis see on, mida see teeb ja miks see eriline on?

Ma tean, et inimesed ajavad mõnikord blu_active ja blu_spark segamini. blu_active on vaid väike osa võrreldes kogu ülejäänud [tööga], mida ma teen.

Põhimõtteliselt teeb protsessori kuberner otsused protsessori sageduste suurendamiseks või vähendamiseks vastavalt süsteemi vajadustele. Alates selle algusest on kuberneril olnud mitmeid muudatusi ja mutatsioone. Nagu kõik muu, mida teen, vajasin ma midagi, mis rahuldaks minu vajadused. See põhineb minu lemmikkuberneril, interaktiivsel kuberneril. Alguses panin sellele lihtsalt mõned ülesvoolu asjad, kuid siis hakkasin lisama mõnda muud kraami, näiteks CAF-i värskendusi või loogikat, mida olin näinud teistes valitsejates ja mis minu jaoks kasulikud olid. Lisasin ka HMP-ühilduvuse ja muud head-paremat.

Uusim iteratsioon põhineb Google'i Linux 4.4 Androidi harul, mis sisaldab ka mõningaid ülesvoolu ja CAF-parandusi, kuid varasemast palju lahjem. Kasutage lihtsalt seda, mis teil on, täielikult, eemaldage see, mida teil pole. Üritan alati saada paremat akut kui varuseadetega, vähendades tühjenemist, püüdes samal ajal parandada esitus (päris elus esinemine, see, mida tunnete silmade ja sõrmedega, mitte sünteetikaga tööriistad).

Kunagi tahtsin ma lihtsat häälestatavat, et inimesed saaksid jõudlusega lihtsal viisil ringi mängida. Nii sündis Fastlane :). Loogika sarnaneb mõnevõrra Honda VTEC-i tööviisiga: mängige ajastustega alates etteantud lävest. Nii et lihtsa lüliti ja muutuva läviväärtusega võiks inimestel olla otsesem ja agressiivsem protsessori sageduse skaleerimine. Varem või hiljem sisestamine vastavalt süsteemi koormusele, sihtkoormustest mööda minnes. See ühildub täielikult HMP-ga ja seda saab kohandada iga klastri kohta vastavalt inimeste vajadustele, täpselt häälestada iga seadme jaoks, milles see töötab.

Millised sisseehitatud mehhanismid või näpunäited teile meeldivad/ei meeldi, mida originaalseadmete tootjad pakuvad? st Qualcommi sisendi võimendus.

Mõned kasutajaruumi võimendused ja muud häälestatavad funktsioonid, mis on seatud HAL-idesse (riistvara abstraktsioonikihid), kõvakodeeritud raamistik jne, võivad mõnikord olla tüütud. Muidugi on teada, et tuumaarendajad töötavad mõne sellise ümber Nexus 5 puhul, näiteks vabanes enamik meist mpdecisionist ja sai kohandatud hotplugi – meil oli sel ajal paigas blu_plug. Mõnel teisel seadmel oli halb soojusjuhtimine ja kohandatud termoregulatsioon koos süsteemidega temperatuuritasemete, leevendussageduse jms jaoks. Mõnel uuemal seadmel on aku, tuumade lahtiühendamise ja muu "madalal tasemel" ranged eeskirjad, mis ei toonud seadme kasutamist tegelikku kasu. Tegelikult rikkus see mõnikord isegi kasutajakogemust, mistõttu oli vaja CTL ja BCL tehnoloogiaid taltsutada.

Mäletan ka krüptimise eemaldamist seadmetes, kui see oli asi, kõik muudatused SELinuxi iteratsioonid tõid sisse muudatusi, mis panid varasemad häkkimised teistmoodi tööle... mõned hiljutised Androidi turvamuudatused on pidevaks väljakutseks. Nende hulka kuulub AVB (mõned osad on enamasti tuntud kui dm-verity). Mõned muud muudatused on seadnud piiranguid häälestatavatele ja sysf-i kohtadele, mida tuli teisaldada, kuna meil pole juurdepääsu samadele kohtadele, mis meil varem olid. Enamik neist piirangutest on asjakohasemad varude ROM-ide puhul (milles ma teen suurema osa oma tööst), tavaliselt sillutab see teed ja muudab kohandatud ROM-ide puhul (kus piirangud on madalamad).

Hiljutistes SoC-des, nagu Qualcomm Snapdragon 820 ja 835, on mõned originaalseadmete tootjad lisanud kasutajaruumist mõningaid tõuke, mis on teretulnud ja tegelevad süsteemi pimealadega. Kõik originaalseadmete tootjad pole halvad. Mis puutub kerneli allikasse, siis mida puhtam ja dokumenteeritum allikas on, seda parem.

Milliseid muid funktsioone teile meeldib lisada? Nagu täiustatud värvijuhtimine jne.

Tavaliselt ma ei lisa asju, mida ma isiklikult ei kasuta või mida ma ei pea kasulikuks. Asjad, mida mulle teha meeldib, hõlmavad lisaks blu_active'ile arhitektuuri optimeerimisi ja parandusi, krüptovärskendusi, IO ajakava ja muud salvestusruumi/failisüsteemi maiuspalad, KCAL, USB kiirlaadimine, vibratsiooni tugevus, aku/märguande LED-juhtimine, Wakelocki blokaatorid, WireGuard, jne. Ehitan alati kohandatud ehitustööriistade ahelaga, nagu ma varem ütlesin.

Millist testimise metoodikat kasutate oma tuuma jaoks? Kas kasutate kasutajaaruandeid, võrdlusuuringuid või muid kohandatud rutiine?

Kõik telefonid, mille jaoks arendan, kuuluvad mulle, seega testitakse kõiki muudatusi alati minuga. Kuna ma sõidan iga päev pikka aega iga seadmega, siis kõik, mis minu jaoks ei sobi, ei tohiks kellelegi teisele sobida. Kui ma järgu avalikult välja annan, on seda juba palju testinud mina ja mõned teised inimesed, keda usaldan kasuliku tagasiside andmiseks. Ma tean, et mõnikord hakkab mõnel kasutajal igav, et kõik asjad töötavad pidevalt nii nagu peab, kuid hindan eelkõige stabiilsust: asetan end alati eelkõige kasutaja kingadesse.

Ma juhin asju reaalse kasutusjuhtumi, mitte sünteetiliste testide suunas. Selline tarkvara on loodud inimestele, mitte tagakontori masinatele. Alguspunkt on alati parem kui aktsiakogemus, igal rindel, aga ma ei hinda tegelikult Antutu viimast rekordit nii palju. Minu tuumad saab häälestada sellisele võrdlusalusele, kuid see pole minu lõppeesmärk. Hindan mõningaid otsesemaid võrdlusaluseid, näiteks IO-salvestuse testimist. Need võivad anda kiire võimaluse kinnitada näiteks hiljuti tehtud muudatusi.

Testin varu-ROM-idega, et saaksin asjadele stabiilse lähtetaseme. Teen kohandatud ROM-ide jaoks kohandatud ehitusi, kuid kohandatud ROM-ide muutlikkuse tõttu, millele on lisatud lisad, öölehed ja isegi mõnede funktsioonide rakendamise erinevus, on võimatu neid kõiki katta ja kõigile korralikku tuge pakkuda, kahjuks.

Samuti koostan mõnikord beetaversioone, et testida midagi konkreetset või kui käivitan beeta-ROM-ide järge või arendaja eelvaateid. Tegin seda Nexuse ja OnePlusi seadmetes, inimestele meeldib vahel asju testida :)


Vaadake 2. osa: F2FS, EAS ja näpunäited ambitsioonikatele tuumaarendajatele