Nemrég interjút készítettünk az eng.stk-vel, a blu_spark kernel fejlesztőjével. Ebben a részben származásáról, fejlesztő munkájáról kérdezzük.
Nemrég lehetőségem nyílt interjút készíteni az XDA vezető tagjával eng.stk, a blu_spark kernel fejlesztője. Fórumainkon számos eszközön elérhető, beleértve a Nexus 5-öt, a OnePlus 3/T-t és a OnePlus 5T-t. Ebben a részben az eng.stk-t kérdezzük a fejlesztési eredetéről és arról, hogyan fejleszti a blu_spark kernelt.
Tehát először mutasd be magad és a kerneledet. Miben különbözik a kerneled a versenytársaktól? Mi az Ön tervezési filozófiája a kernel változtatásokkal kapcsolatban, és hogyan fog hozzá?
eng.stk vagyok, és 2010 óta az XDA-n vagyok. A legtöbben a code_blue és a blu_spark projektjeimből ismernek :)
Az XDA-n azzal kezdtem, hogy írtam néhány szkriptet és különféle eszközöket, keretrendszer-hackeket. Én is csináltam sok témát... Az itt töltött idő alatt közvetlenül is közreműködtem néhány projektben, mint például a Purity ROM, a Universal Kernel Manager, a Kernel Adiutor és újabban a Magisk és WireGuard hogy csak néhányat említsünk. Mostanában TWRP-vel is foglalkoztam (főleg OnePlus eszközökön), Magisk modulokkal és egyéb eszközökkel/hackekkel [amelyek] hasznosak a kernelprojektjeim életciklusa során (ha jól emlékszem, néhány dolog felkerült az XDA portálra helyesen). A blu_spark kernel nemcsak kernellé kezdett válni, hanem egy átfogó élmény a kernel, az eszközláncok, a helyreállítás, a témakezelés, az eszközök, a szkriptek stb. között. De a kernelmunka az, amit a legjobban élvezek, és ami hajt.
Mindig is szerettem feltörni, és kódokat/szkripteket készíteni, amikor lehetőségem volt rá (az elektronikus játékok szétszerelése és az alapvető kódolás az unokatestvérem Commodore 64-én szórakoztató volt). Számomra a kódolás nem egy eszköz a cél eléréséhez, hanem csak egy eszköz, mint mások, egy meghatározott cél eléréséhez. A legtöbb komolyabb dolgom és munkám alapjai akkor készültek, amikor serdülőkoromban/huszonéves korom elején felfedeztem a Linuxot. Később, valahol az egyetemi időkben számomra az Android volt a logikus következő lépés: tényleg egy bütykös álom, ahol sokat lehetett játszani hardverrel vagy szoftverrel.
A legjobb szavak a blu_spark leírására az optimalizálás és a stabilitás. Azok, akik használják, tudják, hogy számíthatnak rá. A kernel buildjeim némileg "többek" olyan módon, hogy hajlamos vagyok nem távolítani néhány elérhető anyagot a dobozból, mindent opcionálisan tartok, hogy az emberek dönthessenek. Nem szeretek túl sok cuccot hozzáadni, csak megváltoztatom vagy hozzáadom azt, amit a legjobbnak tartok az adott területen. A CPU-frekvencia-illesztőprogram, az IO ütemező, a hálózati protokollok, a fájlrendszerek stb., vagy módosíthat néhány hangolható beállítást bizonyos paraméterekhez, vagy upstream néhány illesztőprogramot a lehető legjobb eredmény érdekében. Egyedi szerszámláncokat is készítek (a Linaro-tól, fantasztikus a GCC-vel), főleg azért, hogy a legjobbat hozzam ki az architektúrából.
A lényeg, a legtöbben attól a pillanattól kezdve tudják, hogy a blu_spark-on vannak, amikor felvillantják a kernelt az eszközön. Mindig keresek új dolgokat és módokat arra, hogy a lehető legjobb felhasználói élményt nyújtsam. Biztonságosan.
Meséljen nekünk a blu_active kormányzójáról! Mi ez, mit csinál és miért különleges?
Tudom, hogy az emberek néha összekeverik a blu_active-ot a blu_spark-kal. A blu_active csak egy kis része az általam végzett többi [munkához] képest.
A CPU-irányító alapvetően dönt arról, hogy a CPU-frekvenciákat a rendszer igényei szerint növelje vagy csökkentse. A kormányzó számos változáson és mutáción ment keresztül kezdete óta. Mint minden máshoz, nekem is szükségem volt valamire, ami kielégíti az igényeimet. A kedvenc kormányzómon, az interaktív kormányzón alapul. Az elején csak néhány upstream cuccot tettem rá, de aztán elkezdtem hozzáadni más dolgokat is, például CAF-frissítéseket vagy más kormányzóknál látott logikát, amelyeket hasznosnak találtam. Hozzáadtam a HMP-kompatibilitást és néhány egyéb finomságot is.
A legújabb iteráció a Google Linux 4.4 Android ágán alapul, néhány upstream és CAF javítással is, de sokkal karcsúbb, mint korábban. Egyszerűen használja teljesen, amije van, és távolítsa el, ami nincs. Mindig igyekszem jobb akkumulátort szerezni, mint a készletbeállításokkal, csökkentve a lemerülést, miközben próbálok javítani teljesítmény (valódi teljesítmény, az, amit a szemével és az ujjaival érez, nem a szintetikus eszközök).
Valamikor egy egyszerű hangolhatót szerettem volna, hogy az emberek egyszerű módon játszhassanak a teljesítménnyel. Így született meg a Fastlane :). A logika némileg hasonló a Honda VTEC működéséhez: játsszon az időzítésekkel egy adott küszöbértéktől. Tehát egy egyszerű kapcsolóval és egy változó küszöbértékkel az emberek közvetlenebb és agresszívebb cpu-frekvencia-skálázást érhetnek el. Előbb-utóbb a rendszerterhelésnek megfelelően történő beléptetése, megkerülve a célterheléseket. Teljesen kompatibilis a HMP-vel, és fürtönként módosítható az emberek igényei szerint, finoman hangolva minden egyes futó eszközhöz.
Milyen beépített mechanizmusokat vagy finomításokat szeret/nem szeret az OEM-ek által? azaz a Qualcomm input boost.
Néha bosszantóak lehetnek bizonyos felhasználói tér-bővítések és egyéb hangolhatók, amelyek HAL-okban (Hardware Abstraction Layers) vannak beállítva, keménykódolt keretrendszer stb. Természetesen a kernelfejlesztők köztudottan megkerülnek néhányat a Nexus 5-ön, például a legtöbbünk megszabadult az mpdecision-tól, és egyedi hotplug-ot kapott – akkoriban a blu_plug a helyén volt. Néhány más eszköz rossz hőkezeléssel és egyedi hőszabályozással rendelkezett a hőmérsékleti szintekhez, a mérséklési frekvenciához stb. Egyes újabb eszközök szigorú szabályzatot alkalmaznak az akkumulátorral, a magok kihúzásával és más „alacsony szinten” lévő dolgokkal kapcsolatban, amelyek nem eredményeztek valódi előnyt az eszközhasználatban. Ami azt illeti, néha még a felhasználói élményt is tönkreteszi, ezért kellett a CTL és BCL technológiákat megszelídíteni.
Arra is emlékszem, hogy eltávolítottam a titkosítást az eszközökről, amikor ez szóba került, a SELinux iterációinak összes változtatása olyan változtatásokat vezetett be, amelyek miatt a korábbi hackek más módon működtek... néhány közelmúltbeli Android biztonsági változás állandó kihívást jelent. Ezek közé tartozik az AVB (egyes részek többnyire dm-verity néven ismertek). Néhány más változtatás korlátozta a hangolható és sysf helyeket, amelyeket át kellett helyezni, mert nem férünk hozzá ugyanazokhoz a helyekhez, mint korábban. E korlátozások többsége inkább a készlet ROM-okra vonatkozik (amelyekben a legtöbb munkámat végzem), általában kikövezi az utat, és megkönnyíti az egyéni ROM-ok esetében (ahol alacsonyabbak a korlátozások).
A legutóbbi SoC-kben, mint például a Qualcomm Snapdragon 820 és 835, egyes OEM-gyártók a felhasználói teret erősítették, ami üdvözlendő, és megoldja a rendszer vakfoltjait, nem minden OEM-cucc rossz. Ha a kernelforrásról van szó, minél tisztább és dokumentáltabb a forrás, annál jobb.
Milyen egyéb funkciókat szeretne beépíteni? Ilyen például a fejlett színszabályozás, és így tovább.
Általában nem veszek bele olyan dolgokat, amelyeket személyesen nem használok, vagy amelyeket nem találok hasznosnak. Amiket szeretek csinálni, a blu_active mellett ide tartozik az architektúra optimalizálása és javítása, a titkosítási cuccok frissítése, az IO ütemezés és egyebek tárolási/fájlrendszeri finomságok, KCAL, USB gyorstöltés, rezgés erőssége, akkumulátor/értesítés LED vezérlés, Wakelock blokkolók, WireGuard, stb. Mindig egyedi összeállítású eszközlánccal építek, ahogy korábban mondtam.
Milyen tesztelési módszertant használ a kernelhez? Használ felhasználói jelentéseket, benchmarkokat vagy bármilyen más egyéni rutint?
Minden telefonom az én tulajdonomban van, amihez fejlesztek, így minden változtatást mindig én tesztelek. Mivel minden eszközt hosszú ideig vezetek naponta, bármit, amit nem találok megfelelőnek, senki másnak nem szabad megtennie. Amikor nyilvánosan kiadok egy buildet, már rengeteg tesztelést végeztem tőlem és néhány olyan személytől, akikben bízom abban, hogy hasznos visszajelzést adnak. Tudom, hogy néha egyes felhasználók megunják, hogy állandóan minden úgy működik, ahogy kell, de én mindenekelőtt a stabilitást értékelem: mindig a felhasználó helyébe helyezem magam.
A dolgokat valós felhasználási esetre irányítom, nem szintetikus tesztekre. Ez a fajta szoftver embereknek készült, nem egy háttérirodában lévő gépeknek. A kiindulópont mindig jobb, mint a tőzsdei tapasztalat, minden fronton, de nem igazán értékelem annyira a legújabb Antutu csúcspontot. A kerneleimet be lehet hangolni erre a fajta benchmarkra, de nem ez a végső célom. Nagyra értékelek néhány közvetlenebb referenciaértéket, például az IO-tárolás tesztelését. Gyors módot nyújthatnak például néhány nemrégiben végrehajtott változtatás érvényesítésére.
A teszteléseimet készlet ROM-okkal végzem, hogy stabil alapállapotom legyen a dolgokhoz. Egyedi buildeket készítek egyedi ROM-okhoz, de az egyedi ROM-ok ingatag jellege miatt hozzáadott extrákkal, éjszakai albumokkal és még egyes funkciók megvalósítási különbségei, lehetetlen mindegyiket lefedni, és mindenkinek megfelelő támogatást nyújtani, sajnálatos módon.
Néha béta buildeket is készítek, hogy teszteljek valami konkrétat, vagy amikor béta ROM-okra vagy fejlesztői előnézetekre indítok buildeket. Ezt a Nexus és OnePlus eszközökön csináltam, az emberek szeretik néha tesztelni a dolgokat :)
Nézze meg a 2. részt: F2FS, EAS és tippek törekvő kernelfejlesztőknek