We hebben onlangs eng.stk geïnterviewd, de ontwikkelaar van de blu_spark-kernel. In dit deel vragen we hem naar zijn afkomst en ontwikkelingswerk.
Ik kreeg onlangs de kans om XDA Senior Member te interviewen nl.stk, ontwikkelaar van de blu_spark-kernel. Het is beschikbaar op veel apparaten op onze forums, waaronder de Nexus 5, OnePlus 3/T en de OnePlus 5T. In dit deel vragen we eng.stk naar zijn oorsprong in de ontwikkeling en hoe hij de blu_spark-kernel ontwikkelt.
Dus stel eerst jezelf en je kernel voor. Hoe onderscheidt jouw kernel zich van de concurrentie? Wat is uw ontwerpfilosofie voor kernelwijzigingen, en hoe gaat u hiermee om?
Ik ben eng.stk en ben sinds 2010 actief op XDA. De meesten van jullie kennen mij van mijn code_blue en blu_spark projecten :)
Ik begon op XDA met het schrijven van een aantal scripts en diverse tools, framework-hacks. Ik heb ook veel aan thema's gedaan... Tijdens mijn tijd hier heb ik ook rechtstreeks meegewerkt aan een aantal projecten zoals Purity ROM, Universal Kernel Manager, Kernel Adiutor en meer recentelijk Magisk en Draadbeschermer om er een paar te noemen. Ik heb de laatste tijd ook wat TWRP-werk gedaan (vooral op OnePlus-apparaten), Magisk-modules en andere tools/hacks [die] nuttig zijn tijdens de levenscyclus van mijn kernelprojecten (sommige dingen zijn op de XDA Portal terechtgekomen als ik me goed herinner correct). blu_spark kernel begon niet alleen een kernel te worden, maar een allesomvattende ervaring tussen kernel, toolchains, herstel, thema's, tools, scripts, enz. Maar kernelwerk is wat ik het leukst vind en wat mij drijft.
Ik vond het altijd leuk om wat code/scripts te hacken en te bouwen als ik de kans had (het demonteren van elektronisch speelgoed en basiscodering op de Commodore 64 van mijn neef was leuk). Voor mij is coderen geen middel om een doel te bereiken, maar slechts een hulpmiddel zoals sommige andere om een bepaald doel te bereiken. De meeste van mijn serieuzere dingen en de basis van mijn werk zijn gedaan toen ik Linux ontdekte tijdens mijn adolescentie/begin twintig. Later, ergens in de tijd van de universiteit, was Android voor mij de logische volgende stap: een droom voor elke knutselaar, waar veel met hardware of software gespeeld kon worden.
De beste woorden om blu_spark te beschrijven zijn optimalisatie en stabiliteit. Mensen die het gebruiken, weten dat ze erop kunnen vertrouwen. Mijn kernelbuilds zijn enigszins 'stockish' in die zin dat ik de neiging heb sommige dingen die beschikbaar zijn niet uit de doos te verwijderen, waarbij ik alles optioneel houd zodat mensen kunnen kiezen. Ik hou er niet van om te veel dingen toe te voegen, ik verander of voeg gewoon toe wat ik het beste vind voor elk bepaald veld. Het CPU-freq-stuurprogramma, de IO-planner, de netwerkprotocollen, de bestandssystemen enz. Of pas een aantal tuneables aan voor bepaalde parameters of stroomopwaarts enkele stuurprogramma's voor het best mogelijke resultaat. Ik bouw ook op maat gemaakte toolchains (van Linaro, geweldige versie van GCC), voornamelijk om het beste uit de architectuur te halen.
Kortom, de meeste mensen weten dat ze blu_spark gebruiken vanaf het moment dat ze de kernel op het apparaat flashen. Ik ben altijd op zoek naar nieuwe dingen en manieren om de best mogelijke UX te geven. Veilig.
Vertel ons over uw blu_active-gouverneur! Wat is het, wat doet het en waarom is het bijzonder?
Ik weet dat mensen blu_active soms verwarren met blu_spark. blu_active is slechts een klein onderdeel vergeleken met de rest van het werk dat ik doe.
De CPU-regelaar neemt in principe beslissingen om de CPU-frequenties omhoog of omlaag te laten gaan, afhankelijk van de behoeften van het systeem. De gouverneur heeft sinds zijn oprichting verschillende veranderingen en mutaties ondergaan. Net als al het andere dat ik doe, had ik iets nodig dat aan mijn behoeften voldeed. Het is gebaseerd op mijn favoriete gouverneur, de interactieve gouverneur. In het begin heb ik er gewoon wat upstream-dingen op gezet, maar daarna begon ik wat andere dingen toe te voegen, zoals CAF-updates of logica die ik bij andere gouverneurs had gezien en die ik nuttig vind. Ik heb ook HMP-compatibiliteit en enkele andere goodies toegevoegd.
De nieuwste versie is gebaseerd op Google's Linux 4.4 Android-tak, met ook enkele upstream- en CAF-oplossingen, maar veel slanker dan voorheen. Maak gewoon optimaal gebruik van wat je hebt, en verwijder wat je niet hebt. Ik probeer altijd een betere batterij te krijgen dan met standaardinstellingen, waardoor het verbruik wordt verminderd en ik probeer te verbeteren prestaties (prestaties in het echte leven, die u voelt met uw ogen en vingers, niet bij synthetische hulpmiddelen).
Op een gegeven moment wilde ik een eenvoudige tune, zodat mensen op een eenvoudige manier met de prestaties konden spelen. Zo werd Fastlane geboren :). De logica lijkt enigszins op de manier waarop Honda VTEC werkt: speel met timings vanaf een bepaalde drempel. Met een simpele schakelaar en een variabele drempelwaarde zouden mensen dus een directere en agressievere cpu-frequentieschaling kunnen realiseren. Het vroeg of laat binnen laten komen afhankelijk van de systeembelasting, waarbij doelbelastingen worden omzeild. Het is volledig compatibel met HMP en kan per cluster worden aangepast aan de behoeften van mensen, nauwkeurig afgestemd op elk apparaat waarop het draait.
Welke ingebouwde mechanismen of aanpassingen vind je leuk/niet leuk die OEM's bieden? dat wil zeggen de inputboost van Qualcomm.
Sommige gebruikersruimteboosts en andere afstemmingen die zijn ingesteld in HAL's (Hardware Abstraction Layers), hardgecodeerde framework-dingen enz., kunnen soms vervelend zijn. Natuurlijk is het bekend dat kernelontwikkelaars een aantal daarvan omzeilen. Op de Nexus 5 hebben de meesten van ons bijvoorbeeld mpdecision afgeschaft en een aangepaste hotplug gekregen - we hadden destijds blu_plug. Sommige andere apparaten hadden een slecht thermisch beheer en een aangepaste thermische controle met sysfs voor temperatuurniveaus, mitigatiefrequentie enz. Sommige recentere apparaten hebben een streng beleid ten aanzien van de batterij, het loskoppelen van kernen en andere dingen op "lage niveaus" die geen echte winst in het apparaatgebruik opleverden. In feite verpestte het soms zelfs de gebruikerservaring, dus het was nodig om de CTL- en BCL-technologieën te temmen.
Ik herinner me ook dat ik encryptie op apparaten verwijderde toen dat nog een ding was, alle veranderingen die SELinux-iteraties introduceerden veranderingen die ervoor zorgden dat eerdere hacks op een andere manier werkten... Sommige recente Android-beveiligingswijzigingen vormen een constante uitdaging. Deze omvatten AVB (sommige delen staan meestal bekend als dm-verity). Enkele andere wijzigingen hebben beperkingen aangebracht voor tunables en sysfs-plaatsen die moesten worden verplaatst omdat we geen toegang hebben tot dezelfde plaatsen als voorheen. De meeste van deze beperkingen zijn relevanter voor stock-ROM's (waarin ik het grootste deel van mijn werk doe), normaal gesproken effent het de weg en maakt het het gemakkelijker als het gaat om aangepaste ROM's (waar de beperkingen lager zijn).
In recente SoC's zoals de Qualcomm Snapdragon 820 en 835 hebben sommige OEM's enkele verbeteringen vanuit de gebruikersruimte toegevoegd die welkom zijn en blinde vlekken in het systeem aanpakken, niet alle OEM-dingen zijn slecht. Als het om de kernelbron gaat, geldt: hoe schoner en beter gedocumenteerd de bron is, hoe beter.
Welke andere functies zou je graag willen toevoegen? Zoals geavanceerde kleurcontrole, enzovoort.
Normaal gesproken neem ik geen dingen op die ik niet persoonlijk gebruik of die ik niet nuttig vind. Dingen die ik graag doe, naast blu_active, omvatten architectuuroptimalisaties en -reparaties, updates van crypto-dingen, IO-planning en andere extra's voor opslag/bestandssysteem, KCAL, snel opladen via USB, trillingssterkte, led-bediening voor batterij/melding, Wakelock-blokkers, WireGuard, enz. Ik bouw altijd met een op maat gemaakte toolchain, zoals ik al eerder zei.
Welke testmethodologie gebruikt u voor uw kernel? Maakt u gebruik van gebruikersrapporten, benchmarks of andere aangepaste routines?
Ik bezit elke telefoon waarvoor ik ontwikkel, dus eventuele wijzigingen worden altijd door mij getest. Omdat ik dagelijks lange tijd met elk apparaat rijd, zou alles wat ik niet geschikt vind voor mij, voor niemand anders geschikt moeten zijn. Wanneer ik een build publiekelijk vrijgeef, is deze al veel getest door mij en een aantal andere mensen van wie ik vertrouw dat ze nuttige feedback zullen geven. Ik weet dat sommige gebruikers zich soms vervelen omdat alles voortdurend werkt zoals het hoort, maar ik waardeer vooral stabiliteit: ik plaats mezelf in de eerste plaats altijd in de schoenen van een gebruiker.
Ik richt de zaken op een real-life use case, niet op synthetische tests. Dit soort software is gemaakt voor mensen, niet voor machines in een backoffice. Het startpunt is altijd beter dan aandelenervaring, op alle fronten, maar ik waardeer de nieuwste Antutu-hoge score niet zo veel. Mijn kernels kunnen worden afgestemd op dit soort benchmarks, maar het is niet mijn einddoel. Ik waardeer sommige benchmarks die directer zijn, zoals bijvoorbeeld het testen van IO-opslag. Ze kunnen een snelle manier bieden om bijvoorbeeld onlangs aangebrachte wijzigingen door te voeren.
Ik voer mijn tests uit met stock-ROM's, zodat ik een stabiele basis voor dingen kan hebben. Ik doe aangepaste builds voor aangepaste ROM's, maar vanwege de vluchtige aard van aangepaste ROM's met toegevoegde extra's, nachtelijke ROM's en zelfs implementatieverschillen bij sommige functies, het is onmogelijk om ze allemaal te behandelen en iedereen de juiste ondersteuning te bieden, Helaas.
Ik bouw soms ook bètabuilds om iets specifieks te testen of voor wanneer ik builds lanceer naar bèta-ROM's of previews voor ontwikkelaars. Dat heb ik gedaan op de Nexus- en OnePlus-toestellen, mensen testen soms graag dingen :)
Bekijk deel 2: F2FS, EAS en tips voor aspirant-kernelontwikkelaars