Wywiad z programistą eng.stk Część 1: Początki i rozwój jądra

Niedawno przeprowadziliśmy wywiad z eng.stk, twórcą jądra blu_spark. W tej części pytamy go o początki i pracę rozwojową.

Niedawno miałem okazję przeprowadzić wywiad ze starszym członkiem XDA ang.stk, twórca jądra blu_spark. Jest ona dostępna na wielu urządzeniach na naszych forach, w tym na Nexusie 5, OnePlus 3/T i OnePlus 5T. W tej części pytamy eng.stk o jego początki w rozwoju i sposób, w jaki rozwija jądro blu_spark.


Najpierw przedstaw siebie i swoje jądro. Jak Twoje jądro wyróżnia się na tle konkurencji? Jaka jest Twoja filozofia projektowania zmian w jądrze i jak się do nich odnosisz?

Nazywam się eng.stk i jestem na XDA od 2010 roku. Większość z Was zna mnie z moich projektów code_blue i blu_spark :)

Zacząłem na XDA pisząc kilka skryptów i różnych narzędzi, hacki frameworkowe. Zrobiłem też wiele motywów... Podczas mojego pobytu tutaj współpracowałem także bezpośrednio przy niektórych projektach, takich jak Purity ROM, Universal Kernel Manager, Kernel Adiutor, a ostatnio Magisk i WireGuard
żeby wymienić tylko kilka. Ostatnio zajmowałem się także TWRP (szczególnie na urządzeniach OnePlus), modułami Magisk i innymi narzędziami/hackami [które są] przydatne w cyklu życia moich projektów jądra (niektóre rzeczy trafiły do ​​portalu XDA, jeśli pamiętam prawidłowo). Jądro blu_spark zaczęło stać się nie tylko jądrem, ale wszechstronnym doświadczeniem pomiędzy jądrem, łańcuchami narzędzi, odzyskiwaniem, motywami, narzędziami, skryptami itp. Ale praca z jądrem jest tym, co lubię najbardziej i co mnie napędza.

Zawsze lubiłem hakować i tworzyć kod/skrypty, kiedy tylko miałem okazję (demontaż elektronicznych zabawek i podstawowe kodowanie na Commodore 64 mojego kuzyna było świetną zabawą). Dla mnie kodowanie nie jest środkiem do celu, ale po prostu narzędziem, takim jak inne, do osiągnięcia określonego celu. Większość moich poważniejszych rzeczy i podstaw mojej pracy powstała, gdy odkryłem Linuksa w okresie dojrzewania lub na początku lat dwudziestych. Później, gdzieś w czasach uniwersyteckich, Android był dla mnie logicznym kolejnym krokiem: marzeniem majsterkowicza, w którym można było dużo bawić się sprzętem i oprogramowaniem.

Najlepszymi słowami opisującymi blu_spark są optymalizacja i stabilność. Osoby, które z niego korzystają wiedzą, że można na nim polegać. Moje kompilacje jądra są w pewnym sensie „sztuczne” w taki sposób, że zwykle nie usuwam niektórych rzeczy dostępnych od razu po wyjęciu z pudełka, pozostawiając wszystko opcjonalne, aby ludzie mogli wybierać. Nie lubię dodawać za dużo rzeczy, po prostu zmieniam lub dodaję to, co uważam za najlepsze dla danej dziedziny. Sterownik częstotliwości procesora, harmonogram IO, protokoły sieciowe, systemy plików itp. lub dostosuj niektóre ustawienia dla niektórych danych parametrów lub prześlij niektóre sterowniki, aby uzyskać najlepszy możliwy wynik. Buduję także niestandardowe zestawy narzędzi (od Linaro, świetna wersja GCC), głównie po to, aby wydobyć to, co najlepsze z architektury.

Podsumowując, większość ludzi wie, że korzysta z blu_spark od chwili flashowania jądra na urządzeniu. Zawsze poszukuję nowych rzeczy i sposobów na zapewnienie najlepszego możliwego UX. Bezpiecznie.

Opowiedz nam o swoim gubernatorze blu_active! Co to jest, co robi i dlaczego jest wyjątkowe?

Wiem, że ludzie czasami mylą blu_active z blu_spark. blu_active to tylko niewielka część w porównaniu z całą resztą [pracy], którą wykonuję.

Gubernator procesora zasadniczo podejmuje decyzje o zwiększeniu lub zmniejszeniu częstotliwości procesora, w zależności od potrzeb systemu. Od początku istnienia gubernator przeszedł kilka zmian i mutacji. Podobnie jak wszystko inne, co robię, potrzebowałem czegoś, co spełni moje potrzeby. Opiera się na moim ulubionym gubernatorze, interaktywnym gubernatorze. Na początku po prostu umieściłem w nim trochę upstreamowych rzeczy, ale potem zacząłem dodawać inne rzeczy, takie jak aktualizacje CAF lub logikę, którą widziałem u innych zarządców, a które uważam za przydatne. Dodałem także kompatybilność z HMP i kilka innych gadżetów.

Najnowsza wersja opiera się na gałęzi Google Linux 4.4 na Androida, z pewnymi poprawkami nadrzędnymi i CAF, ale znacznie bardziej uproszczona niż wcześniej. Po prostu wykorzystaj w pełni to, co masz, usuń to, czego nie potrzebujesz. Zawsze staram się uzyskać lepszą baterię niż przy ustawieniach fabrycznych, zmniejszając zużycie energii i próbując ją ulepszyć wydajność (wydajność z życia wzięta, taka, którą czujesz oczami i palcami, a nie sztuczną). narzędzia).

W pewnym momencie chciałem prostego narzędzia do dostrajania, aby ludzie mogli w prosty sposób bawić się wydajnością. Tak narodził się Fastlane :). Logika jest nieco podobna do sposobu działania Hondy VTEC: baw się rozrządu od zadanego progu. Tak więc, dzięki prostemu przełącznikowi i zmiennej wartości progowej, ludzie mogliby uzyskać bardziej bezpośrednie i agresywne skalowanie częstotliwości procesora. Wprowadzanie go prędzej czy później w zależności od obciążenia systemu, z pominięciem obciążeń docelowych. Jest w pełni kompatybilny z HMP i można go dostosowywać w każdym klastrze zgodnie z potrzebami użytkowników, precyzyjnie dostrojony do każdego urządzenia, na którym działa.

Jakie wbudowane mechanizmy lub usprawnienia oferowane przez producentów OEM lubisz/nie lubisz? tj. wzmocnienie wejścia Qualcomm.

Niektóre ulepszenia przestrzeni użytkownika i inne możliwości strojenia ustawione w warstwach HAL (warstwy abstrakcji sprzętu), zakodowane na stałe elementy frameworku itp. mogą czasami być denerwujące. Oczywiście wiadomo, że twórcy jądra obchodzą niektóre z nich. Na przykład na Nexusie 5 większość z nas pozbyła się mpdecision i dostała niestandardową wtyczkę typu hotplug - mieliśmy wtedy zainstalowaną wtyczkę blu_plug. Niektóre inne urządzenia miały złe zarządzanie temperaturą i niestandardową kontrolę termiczną za pomocą sysfs dla poziomów temperatury, częstotliwości łagodzenia itp. Niektóre nowsze urządzenia mają pewne twarde zasady dotyczące baterii, odłączania rdzeni i innych rzeczy na „niskim poziomie”, które nie przynoszą rzeczywistego wzrostu w użytkowaniu urządzenia. Prawdę mówiąc, czasami psuło to nawet doświadczenie użytkownika, dlatego konieczne było ujarzmienie technologii CTL i BCL.

Pamiętam też usunięcie szyfrowania w urządzeniach, kiedy o to chodziło, wszystkie zmiany iteracje SELinux wprowadziły zmiany, które sprawiły, że poprzednie hacki działały w inny sposób… niektóre niedawne zmiany w zabezpieczeniach Androida stanowią ciągłe wyzwanie. Należą do nich AVB (niektóre części znane są głównie jako dm-verity). Niektóre inne zmiany wprowadziły ograniczenia dla miejsc strojonych i sysfs, które musiały zostać przeniesione, ponieważ nie mamy dostępu do tych samych miejsc, które mieliśmy wcześniej. Większość z tych ograniczeń dotyczy bardziej standardowych ROM-ów (w których wykonuję większość mojej pracy), zwykle toruje drogę i ułatwia, jeśli chodzi o niestandardowe ROM-y (gdzie ograniczenia są mniejsze).

W najnowszych SoC, takich jak Qualcomm Snapdragon 820 i 835, niektórzy producenci OEM dodali pewne ulepszenia z przestrzeni użytkownika, które są mile widziane i eliminują martwe punkty w systemie. Nie wszystkie produkty OEM są złe. Jeśli chodzi o źródło jądra, im czystsze i lepiej udokumentowane jest źródło, tym lepiej.

Jakie inne funkcje chcesz uwzględnić? Takie jak zaawansowana kontrola kolorów i tak dalej.

Zwykle nie uwzględniam rzeczy, których osobiście nie używam lub które nie wydają mi się przydatne. Rzeczy, które lubię robić, poza blu_active, obejmują optymalizacje i poprawki architektury, aktualizacje kryptowalut, planowanie IO i inne dodatki do przechowywania/systemu plików, KCAL, szybkie ładowanie USB, siła wibracji, sterowanie diodą LED baterii/powiadomień, blokowanie Wakelock, WireGuard, itp. Zawsze buduję przy użyciu niestandardowego zestawu narzędzi do kompilacji, jak powiedziałem wcześniej.

Jakiej metodologii testowania używasz dla swojego jądra? Czy korzystasz z raportów użytkowników, testów porównawczych lub innych niestandardowych procedur?

Jestem właścicielem każdego telefonu, dla którego opracowuję, więc wszelkie zmiany są zawsze testowane przeze mnie. Ponieważ na co dzień jeżdżę każdym urządzeniem przez długi czas, wszystko, co uznam za nieodpowiednie dla mnie, nie powinno pasować dla nikogo innego. Kiedy publikuję publicznie kompilację, przeszła ona już wiele testów przeze mnie i kilka innych osób, którym ufam, że przekazują przydatne opinie. Wiem, że czasami niektórym użytkownikom nudzi się ciągłe działanie wszystkiego tak, jak powinno, ale przede wszystkim cenię stabilność: zawsze stawiam się na miejscu użytkownika.

Kieruję rzeczami w stronę rzeczywistego przypadku użycia, a nie testów syntetycznych. Tego rodzaju oprogramowanie jest tworzone dla ludzi, a nie maszyn w biurze. Punkt wyjścia jest zawsze lepszy niż standardowe doświadczenie, pod każdym względem, ale tak naprawdę nie cenię tak bardzo najnowszego wysokiego wyniku Antutu. Moje jądra można dostroić do tego rodzaju testów porównawczych, ale nie jest to mój ostateczny cel. Cenię sobie niektóre testy porównawcze, które są bardziej bezpośrednie, jak na przykład testowanie pamięci masowej I/O. Mogą na przykład zapewnić szybki sposób potwierdzenia niektórych ostatnio wprowadzonych zmian.

Testuję na standardowych ROMach, żeby mieć stabilną podstawę do działania. Robię niestandardowe kompilacje dla niestandardowych ROM-ów, ale ze względu na zmienny charakter niestandardowych ROM-ów z dodatkowymi dodatkami, klubami nocnymi, a nawet różnice w implementacji niektórych funkcji, nie da się objąć ich wszystkich i zapewnić każdemu odpowiedniego wsparcia, Niestety.

Czasami tworzę także wersje beta, aby przetestować coś konkretnego lub gdy uruchamiam kompilacje do wersji beta ROM lub wersji zapoznawczych programistów. Zrobiłem to na urządzeniach Nexus i OnePlus, ludzie czasami lubią testować różne rzeczy :)


Sprawdź część 2: F2FS, EAS i wskazówki dla początkujących programistów jądra