Am intervievat recent eng.stk, dezvoltatorul nucleului blu_spark. În această parte, îl întrebăm despre originile și munca sa de dezvoltare.
Am avut recent șansa de a intervieva un membru senior XDA ing.stk, dezvoltator al nucleului blu_spark. Este disponibil pe multe dispozitive de pe forumurile noastre, inclusiv Nexus 5, OnePlus 3/T și OnePlus 5T. În această parte, îl întrebăm pe eng.stk despre originile sale în dezvoltare și despre cum dezvoltă nucleul blu_spark.
Așa că mai întâi, prezentați-vă pe voi și nucleul dvs. Cum se diferențiază nucleul tău de concurență? Care este filosofia dvs. de design pentru modificările nucleului și cum procedați în privința acestora?
Sunt eng.stk și sunt pe XDA din 2010. Majoritatea dintre voi mă cunoașteți din proiectele mele code_blue și blu_spark :)
Am început pe XDA scriind niște scripturi și instrumente diverse, hack-uri de framework. Am făcut și multe tematice... În timpul petrecut aici, am colaborat direct la unele proiecte precum Purity ROM, Universal Kernel Manager, Kernel Adiutor și mai recent Magisk și WireGuard doar pentru a numi câteva. Am lucrat și în ultima vreme TWRP (în special pe dispozitive OnePlus), module Magisk și alte instrumente/hack-uri [care sunt] utile în timpul ciclului de viață al proiectelor mele de kernel (unele lucruri au mers pe portalul XDA dacă îmi amintesc corect). Blu_spark kernel a început să devină nu doar un nucleu, ci o experiență completă între kernel, lanțuri de instrumente, recuperare, tematică, instrumente, scripturi etc. Dar munca nucleului este ceea ce îmi place cel mai mult și ceea ce mă motivează.
Întotdeauna mi-a plăcut să joc și să construiesc niște coduri/scripturi când am avut ocazia (dezasamblarea jucăriilor electronice și codificarea de bază pe Commodore 64 al vărului meu a fost distractiv). Pentru mine, codificarea nu este un mijloc pentru atingerea unui scop, ci doar un instrument ca alții pentru a atinge un scop definit. Majoritatea lucrurilor mele mai serioase și a bazelor muncii mele au fost făcute când am descoperit Linux în timpul adolescenței / începutul de douăzeci de ani. Mai târziu, undeva pe vremea universității, Android a fost următorul pas logic pentru mine: visul unui chinuitor, în care hardware-ul sau software-ul puteau fi jucat cu multe.
Cele mai bune cuvinte pentru a descrie blu_spark sunt optimizare și stabilitate. Oamenii care îl folosesc știu că se pot baza pe el. Compilările mele de kernel sunt oarecum „stockish”, într-un mod în care tind să nu scot unele lucruri disponibile din cutie, păstrând totul opțional, astfel încât oamenii să poată alege. Nu-mi place să adaug prea multe lucruri, doar schimb sau adaug ceea ce consider cel mai bun pentru fiecare domeniu dat. Driverul de frecvență al procesorului, planificatorul IO, protocoalele de rețea, sistemele de fișiere etc. sau ajustați unele reglabile pentru unii parametri dați sau în amonte unele drivere pentru cel mai bun rezultat posibil. De asemenea, construiesc lanțuri de instrumente personalizate (de la Linaro, o interpretare minunată a GCC), în principal pentru a obține cele mai bune rezultate din arhitectură.
În concluzie, majoritatea oamenilor știu că sunt pe blu_spark din momentul în care flash kernel-ul pe dispozitiv. Caut mereu lucruri noi și modalități de a oferi cel mai bun UX posibil. În condiții de siguranță.
Povestește-ne despre guvernatorul tău blu_active! Ce este, ce face și de ce este special?
Știu că uneori oamenii confundă blu_active cu blu_spark. blu_active este doar o mică parte în comparație cu restul [din munca] pe care o fac.
Guvernatorul CPU practic ia decizii pentru a face ca frecvențele CPU să crească sau să scadă, în funcție de nevoile sistemului. Guvernatorul a avut mai multe schimbări și mutații de când a început. Ca tot ceea ce fac, aveam nevoie de ceva care să-mi satisfacă nevoile. Se bazează pe guvernatorul meu preferat, guvernatorul interactiv. La început am pus niște chestii din amonte, dar apoi am început să adaug și alte chestii, cum ar fi actualizările CAF sau logica pe care le-am văzut la alți guvernatori care mi se pare utile. Am adăugat și compatibilitatea HMP și alte bunătăți.
Cea mai recentă iterație se bazează pe ramura Android Linux 4.4 a Google, cu unele remedieri în amonte și CAF, dar mult mai slabe decât înainte. Pur și simplu folosiți ceea ce aveți la maximum, eliminați ceea ce nu aveți. Încerc întotdeauna să obțin o baterie mai bună decât cu setările de stoc, reducând consumul, încercând în același timp să mă îmbunătățesc performanță (performanță în viața reală, cea pe care o simți cu ochii și degetele, nu cu materialele sintetice instrumente).
La un moment dat, mi-am dorit un reglabil simplu, astfel încât oamenii să se poată juca cu performanța într-un mod simplu. Asa s-a nascut Fastlane :). Logica este oarecum asemănătoare cu modul în care funcționează Honda VTEC: jucați cu cronometraje de la un anumit prag. Deci, cu o comutare simplă și o valoare de prag variabilă, oamenii ar putea avea o scalare a frecvenței procesorului mai directă și mai agresivă. Făcându-l să intre mai devreme sau mai târziu în funcție de încărcarea sistemului, ocolind sarcinile țintă. Este pe deplin compatibil cu HMP și poate fi ajustat pe cluster în funcție de nevoile oamenilor, reglat fin pentru fiecare dispozitiv pe care rulează.
Ce mecanisme sau ajustări încorporate vă plac/nu vă plac pe care OEM-urile le oferă? adică sporul de intrare de la Qualcomm.
Unele îmbunătățiri ale spațiului utilizator și alte reglabile care sunt setate în HAL-uri (straturi de abstractizare hardware), chestii de cadru hardcoded etc. pot fi uneori enervante. Desigur, se știe că dezvoltatorii de kernel lucrează în jurul unora dintre cei de pe Nexus 5, de exemplu, cei mai mulți dintre noi am scăpat de mpdecision și au primit un hotplug personalizat - aveam blu_plug la momentul respectiv. Alte dispozitive aveau un management termic prost și un control termic personalizat cu sysfs pentru nivelurile de temperatură, frecvența de atenuare etc. Unele dispozitive mai recente au niște politici stricte cu privire la baterie, deconectarea nucleelor și alte lucruri la „niveluri scăzute” care nu au făcut un câștig real în utilizarea dispozitivului. De fapt, chiar a stricat experiența utilizatorului uneori, așa că a fost necesar să se îmblânzească tehnologiile CTL și BCL.
Îmi amintesc, de asemenea, că am eliminat criptarea în dispozitive când asta era un lucru, toate modificările iterațiile SELinux au introdus modificări care au făcut ca hackurile anterioare să funcționeze într-un mod diferit... unele modificări recente de securitate Android reprezintă o provocare constantă. Acestea includ AVB (unele părți cunoscute în principal ca dm-verity). Alte modificări au făcut restricții pentru locurile reglabile și sysfs care au trebuit să fie mutate, deoarece nu avem acces la aceleași locuri pe care le aveam înainte. Cele mai multe dintre aceste restricții sunt mai relevante pentru ROM-urile de stoc (în care îmi fac cea mai mare parte din munca), în mod normal, deschid drumul și ușurează când vine vorba de ROM-uri personalizate (unde restricțiile sunt mai mici).
În SoC-urile recente, cum ar fi Qualcomm Snapdragon 820 și 835, unii producători OEM au adăugat câteva îmbunătățiri din spațiul utilizatorului, care sunt binevenite și abordează punctele moarte din sistem, nu toate lucrurile OEM sunt rele. Când vine vorba de sursa nucleului, cu cât sursa este mai curată și mai documentată, cu atât mai bine.
Ce alte caracteristici vă place să includeți? Cum ar fi controlul avansat al culorilor și așa mai departe.
În mod normal, nu includ lucruri pe care nu le folosesc personal sau pe care nu le consider utile. Lucrurile pe care îmi place să le fac, pe lângă blu_active, includ optimizări și remedieri ale arhitecturii, actualizări criptografice, programarea IO și altele Bunătăți de stocare/sistem de fișiere, KCAL, încărcare rapidă USB, puterea vibrațiilor, control LED pentru baterie/notificări, blocante Wakelock, WireGuard, etc. Construiesc întotdeauna cu un lanț de instrumente personalizat, așa cum am spus mai devreme.
Ce metodologie de testare utilizați pentru nucleul dvs.? Folosiți rapoarte de utilizator, benchmark-uri sau alte rutine personalizate?
Dețin fiecare telefon pentru care dezvolt, așa că orice modificări sunt întotdeauna testate să fiu eu. Deoarece conduc zilnic fiecare dispozitiv pentru o perioadă lungă de timp, orice găsesc că nu este potrivit pentru mine, nu ar trebui să fie potrivit pentru nimeni altcineva. Când lansez public o versiune, aceasta a avut deja multe teste din partea mea și a altor persoane în care am încredere că vor oferi feedback util. Știu că uneori unii utilizatori se plictisesc de a avea în permanență toate lucrurile să funcționeze așa cum ar trebui, dar prețuiesc stabilitatea mai presus de toate: mă pun mereu pe pielea unui utilizator, în primul rând.
Conduc lucrurile spre un caz de utilizare real, nu spre teste sintetice. Acest tip de software este creat pentru oameni, nu pentru mașini dintr-un back office. Punctul de plecare este întotdeauna mai bun decât experiența stocului, pe toate fronturile, dar nu prea prețuiesc cel mai recent scor mare Antutu. Nuezele mele pot fi reglate la acest tip de benchmark, dar nu este scopul meu final. Apreciez unele puncte de referință care sunt mai directe, cum ar fi testarea stocării IO, de exemplu. Ele pot oferi o modalitate rapidă de a afirma unele modificări făcute recent, de exemplu.
Îmi fac testarea cu ROM-uri stoc, astfel încât să pot avea o linie de bază stabilă pentru lucruri. Fac build-uri personalizate pentru ROM-uri personalizate, dar din cauza naturii volatile a ROM-urilor personalizate cu plusuri adăugate, noapte și chiar diferența de implementare a unor caracteristici, este imposibil să le acoperiți pe toate și să oferiți suport adecvat tuturor, din pacate.
De asemenea, uneori construiesc versiuni beta pentru a testa ceva anume sau pentru când lansez versiuni pentru ROM-uri beta sau previzualizări pentru dezvoltatori. Am făcut asta pe dispozitivele Nexus și OnePlus, oamenilor le place să testeze lucruri uneori :)
Consultați partea 2: F2FS, EAS și Sfaturi pentru dezvoltatorii de kernel aspiranți