Наскоро интервюирахме eng.stk, разработчика на ядрото blu_spark. В тази част го питаме за неговия произход и работа по развитие.
Наскоро имах възможност да интервюирам старши член на XDA инж.стк, разработчик на ядрото blu_spark. Предлага се на много устройства в нашите форуми, включително Nexus 5, OnePlus 3/T и OnePlus 5T. В тази част питаме eng.stk за неговия произход в разработката и как разработва ядрото blu_spark.
Така че първо, представете себе си и вашето ядро. Как вашето ядро се отличава от конкуренцията? Каква е вашата философия за проектиране на промените в ядрото и как ги правите?
Аз съм eng.stk и съм в XDA от 2010 г. Повечето от вас ме познават от моите проекти code_blue и blu_spark :)
Започнах с XDA, като написах някои скриптове и различни инструменти, фреймуърк хакове. Направих и много теми... По време на престоя си тук също съм сътрудничил пряко на някои проекти като Purity ROM, Universal Kernel Manager, Kernel Adiutor и по-скоро Magisk и WireGuard само за да назовем няколко. Напоследък също работя с TWRP (особено на устройства OnePlus), модули Magisk и други инструменти/хакове [които са] полезни по време на жизнения цикъл на моите проекти на ядрото (някои неща бяха на портала XDA, ако си спомням правилно). Ядрото на blu_spark започна да се превръща не само в ядро, но и в цялостно изживяване между ядро, вериги от инструменти, възстановяване, тематизиране, инструменти, скриптове и т.н. Но работата с ядрото е това, което ми харесва най-много и което ме движи.
Винаги ми харесваше да хаквам и да създавам някакъв код/скриптове, когато имах възможност (разглобяването на електронни играчки и основното кодиране на Commodore 64 на братовчед ми беше забавно). За мен кодирането не е средство за постигане на цел, а просто инструмент като някои други за постигане на определена цел. Повечето от по-сериозните ми неща и основите на работата ми бяха готови, когато открих Linux по време на юношеството/ранните двадесет години. По-късно, някъде по време на университета, Android беше логичната следваща стъпка за мен: мечтата на майстора, където може да се играе много с хардуер или софтуер.
Най-добрите думи за описание на blu_spark са оптимизация и стабилност. Хората, които го използват знаят, че могат да разчитат на него. Моите компилации на ядрото са донякъде „запасени“ по начин, по който имам склонност да не премахвам някои неща, налични извън кутията, запазвайки всичко по избор, така че хората да могат да избират. Не обичам да добавям твърде много неща, просто променям или добавям това, което смятам за най-добро за всяка дадена област. Драйверът за честота на процесора, планировчикът на IO, мрежовите протоколи, файловите системи и т.н. или настройте някои настройки за някои дадени параметри или нагоре по веригата някои драйвери за възможно най-добрия резултат. Също така изграждам персонализирани вериги от инструменти (от Linaro, страхотна версия на GCC), главно за да извлека най-доброто от архитектурата.
В крайна сметка повечето хора знаят, че са на blu_spark от момента, в който флашнат ядрото на устройството. Винаги търся нови неща и начини да осигуря възможно най-добрия UX. Безопасно.
Разкажете ни за вашия blu_active губернатор! Какво представлява, какво прави и защо е специално?
Знам, че хората понякога бъркат blu_active с blu_spark. blu_active е само малка част в сравнение с цялата останала [от работата], която върша.
Регулаторът на процесора основно взема решения за увеличаване или намаляване на честотите на процесора в зависимост от нуждите на системата. Губернаторът претърпя няколко промени и мутации от началото. Както всичко останало, което правя, имах нужда от нещо, което да отговаря на нуждите ми. Базиран е на любимия ми управител, интерактивния управител. В началото просто сложих някои неща нагоре по веригата, но след това започнах да добавям някои други неща, като CAF актуализации или логика, която бях виждал в други управители, които намирам за полезни. Добавих също HMP съвместимост и някои други екстри.
Последната итерация е базирана на Linux 4.4 Android клона на Google, с някои корекции нагоре и CAF също, но много по-икономична от преди. Просто използвайте пълноценно това, което имате, премахнете това, което нямате. Винаги се опитвам да получа по-добра батерия, отколкото със стандартни настройки, като намалявам разхода, докато се опитвам да подобря производителност (реална производителност, тази, която усещате с очите и пръстите си, а не със синтетика инструменти).
В един момент исках лесна настройка, така че хората да могат да си играят с производителността по лесен начин. Така се роди Fastlane :). Логиката е донякъде подобна на начина, по който работи Honda VTEC: играйте с времената от даден праг. Така че, с прост превключвател и променлива прагова стойност, хората биха могли да имат по-директно и агресивно мащабиране на честотата на процесора. Карайки го да влезе рано или късно според натоварването на системата, заобикаляйки целевите натоварвания. Той е напълно съвместим с HMP и може да се променя на клъстер според нуждите на хората, фино настроен за всяко устройство, на което работи.
Какви вградени механизми или настройки харесвате/не харесвате, които OEM производителите предоставят? т.е. усилване на входа на Qualcomm.
Някои усилвания на потребителското пространство и други настройки, които са зададени в HAL (хардуерни абстракционни слоеве), твърдо кодирани рамки и т.н., понякога могат да бъдат досадни. Разбира се, известно е, че разработчиците на ядрото заобикалят някои от тях. На Nexus 5, например, повечето от нас се отърваха от mpdecision и получиха персонализиран hotplug - по това време имахме blu_plug. Някои други устройства имаха лошо термично управление и персонализиран термичен контрол със sysfs за температурни нива, честота на смекчаване и т.н. Някои по-нови устройства имат някои твърди правила за батерията, изключването на ядрата и други неща в „ниски нива“, които не доведоха до реална печалба при използването на устройството. В интерес на истината понякога дори съсипваше потребителското изживяване, така че беше необходимо да се укротят CTL и BCL технологиите.
Спомням си също премахването на криптирането в устройствата, когато това беше нещо, всички промени, итерациите на SELinux въведоха промени, които накараха предишните хакове да работят по различен начин... някои скорошни промени в сигурността на Android са постоянно предизвикателство. Те включват AVB (някои части са известни като dm-verity). Някои други промени наложиха ограничения за настройваеми и sysfs места, които трябваше да бъдат преместени, защото нямаме достъп до същите места, които имахме преди. Повечето от тези ограничения са по-подходящи за стандартни ROM (в които върша повечето от работата си), обикновено те проправят пътя и го улесняват, когато става въпрос за персонализирани ROM (където ограниченията са по-ниски).
В последните SoC, като Qualcomm Snapdragon 820 и 835, някои OEM производители са добавили някои подобрения от потребителското пространство, които са добре дошли и се справят със слепите точки в системата, не всички OEM неща са лоши. Що се отнася до източника на ядрото, колкото по-чист и документиран е източникът, толкова по-добре.
Какви други функции искате да включите? Като разширен контрол на цветовете и т.н.
Обикновено не включвам неща, които не използвам лично или които не намирам за полезни. Нещата, които обичам да правя, освен blu_active, включват оптимизации и корекции на архитектурата, актуализации на крипто неща, IO планиране и други екстри за съхранение/файлова система, KCAL, USB бързо зареждане, сила на вибрация, LED контрол на батерията/известия, блокери на Wakelock, WireGuard, и т.н. Винаги изграждам с персонализирана верига от инструменти за изграждане, както казах по-рано.
Каква методология за тестване използвате за вашето ядро? Използвате ли потребителски отчети, бенчмаркове или някакви други персонализирани процедури?
Притежавам всеки телефон, за който разработвам, така че всички промени винаги се тестват от мен. Тъй като ежедневно карам всяко устройство за дълъг период от време, всичко, което намирам за неподходящо за мен, не трябва да е подходящо за никой друг. Когато пусна публично компилация, тя вече е преминала много тестове от мен и от някои други хора, на които вярвам, че ще предоставят полезна обратна връзка. Знам, че понякога някои потребители се отегчават от това, че постоянно всички неща работят както трябва, но аз ценя стабилността преди всичко: винаги се поставям на мястото на потребителя на първо място.
Насочвам нещата към случай на реална употреба, а не към синтетични тестове. Този вид софтуер е създаден за хора, а не за машини в бек офис. Началната точка винаги е по-добра от опита със запасите, на всички фронтове, но всъщност не ценя толкова много най-новия висок резултат на Antutu. Моите ядра могат да бъдат настроени към този вид бенчмарк, но това не е крайната ми цел. Оценявам някои бенчмаркове, които са по-директни, като тестване на IO съхранение например. Те могат да предоставят бърз начин за отстояване на някои наскоро направени промени например.
Тествам със стандартни ROM, за да мога да имам стабилна базова линия за нещата. Правя персонализирани компилации за персонализирани ROM, но поради променливия характер на персонализираните ROM с добавени екстри, нощни забавления и дори разлика в изпълнението на някои функции, невъзможно е да ги покрием всички и да предоставим правилна поддръжка на всички, за жалост.
Също така понякога изграждам бета компилации, за да тествам нещо конкретно или когато стартирам компилации на бета ROM или визуализации за разработчици. Направих това на устройствата Nexus и OnePlus, хората обичат понякога да тестват неща :)
Вижте част 2: F2FS, EAS и съвети за амбициозни разработчици на ядро