Wir haben kürzlich eng.stk interviewt, den Entwickler des blu_spark-Kernels. In diesem Teil befragen wir ihn zu seiner Herkunft und seinem Entwicklungswerk.
Ich hatte kürzlich die Gelegenheit, ein XDA-Senior-Mitglied zu interviewen eng.stk, Entwickler des blu_spark-Kernels. Es ist auf vielen Geräten in unseren Foren verfügbar, darunter dem Nexus 5, OnePlus 3/T und dem OnePlus 5T. In diesem Teil fragen wir eng.stk nach seinen Ursprüngen in der Entwicklung und wie er den blu_spark-Kernel entwickelt.
Stellen Sie sich und Ihren Kernel zunächst vor. Wie unterscheidet sich Ihr Kernel von der Konkurrenz? Was ist Ihre Designphilosophie für Kernel-Änderungen und wie gehen Sie dabei vor?
Ich bin eng.stk und seit 2010 auf XDA. Die meisten von euch kennen mich aus meinen code_blue- und blu_spark-Projekten :)
Ich begann mit XDA, indem ich einige Skripte und verschiedene Tools sowie Framework-Hacks schrieb. Ich habe auch viel Thematisierung vorgenommen... Während meiner Zeit hier habe ich auch direkt an einigen Projekten wie Purity ROM, Universal Kernel Manager, Kernel Adiutor und neuerdings Magisk mitgearbeitet WireGuard nur um ein paar zu nennen. Ich habe in letzter Zeit auch einige TWRP-Arbeiten (insbesondere auf OnePlus-Geräten), Magisk-Module und andere Tools/Hacks durchgeführt [die] während des Lebenszyklus meiner Kernel-Projekte nützlich sind (wenn ich mich recht erinnere, gingen einige Dinge auf das XDA-Portal korrekt). Der blu_spark-Kernel entwickelte sich nicht nur zu einem Kernel, sondern zu einem umfassenden Erlebnis zwischen Kernel, Toolchains, Wiederherstellung, Theming, Tools, Skripten usw. Aber die Arbeit am Kernel macht mir am meisten Spaß und treibt mich an.
Es hat mir immer Spaß gemacht, herumzuhacken und ein paar Codes/Skripte zu erstellen, wenn ich die Gelegenheit dazu hatte (das Zerlegen elektronischer Spielzeuge und grundlegendes Programmieren auf dem Commodore 64 meines Cousins hat Spaß gemacht). Für mich ist Codierung kein Mittel zum Zweck, sondern nur ein Werkzeug wie einige andere, um einen definierten Zweck zu erreichen. Die meisten meiner ernsteren Dinge und Grundlagen meiner Arbeit entstanden, als ich Linux in meiner Jugend/Anfang Zwanzig entdeckte. Später, irgendwann während der Studienzeit, war Android für mich der logische nächste Schritt: eigentlich der Traum eines jeden Bastlers, bei dem man viel mit Hardware oder Software spielen konnte.
Die besten Worte, um blu_spark zu beschreiben, sind Optimierung und Stabilität. Wer es nutzt, weiß, dass man sich darauf verlassen kann. Meine Kernel-Builds sind etwas „stockish“, sodass ich dazu neige, einige verfügbare Dinge nicht aus der Box zu entfernen und alles optional zu belassen, damit die Leute wählen können. Ich füge nicht gerne zu viel hinzu, ich ändere oder füge einfach das hinzu, was ich für das jeweilige Feld am besten halte. Den CPU-Frequenztreiber, den E/A-Scheduler, die Netzwerkprotokolle, die Dateisysteme usw. oder optimieren Sie einige einstellbare Parameter für bestimmte Parameter oder schalten Sie einige Treiber vor, um das bestmögliche Ergebnis zu erzielen. Ich baue auch maßgeschneiderte Toolchains (von Linaro, tolle Version von GCC), hauptsächlich um das Beste aus der Architektur herauszuholen.
Unterm Strich wissen die meisten Leute, dass sie blu_spark nutzen, sobald sie den Kernel auf dem Gerät flashen. Ich bin immer auf der Suche nach neuen Dingen und Möglichkeiten, die bestmögliche UX zu bieten. Sicher.
Erzählen Sie uns von Ihrem blu_active Governor! Was ist das, was macht es und warum ist es besonders?
Ich weiß, dass die Leute manchmal blu_active mit blu_spark verwechseln. blu_active ist nur ein kleiner Teil im Vergleich zu all dem Rest [der Arbeit], die ich mache.
Der CPU-Governor trifft grundsätzlich Entscheidungen, um die CPU-Frequenzen je nach den Anforderungen des Systems zu erhöhen oder zu verringern. Der Gouverneur hat seit seiner Gründung mehrere Veränderungen und Mutationen erfahren. Wie alles andere, was ich tue, brauchte ich etwas, das meine Bedürfnisse erfüllte. Es basiert auf meinem Lieblingsgouverneur, dem interaktiven Gouverneur. Am Anfang habe ich nur ein paar Upstream-Sachen hinzugefügt, aber dann habe ich angefangen, ein paar andere Sachen hinzuzufügen, wie CAF-Updates oder Logik, die ich in anderen Governors gesehen habe und die ich nützlich finde. Ich habe auch HMP-Kompatibilität und einige andere Extras hinzugefügt.
Die neueste Version basiert auf Googles Linux 4.4-Android-Zweig, mit einigen Upstream- und CAF-Korrekturen, aber viel schlanker als zuvor. Nutzen Sie einfach das, was Sie haben, voll aus und entfernen Sie, was Sie nicht haben. Ich versuche immer, eine bessere Batterie als mit den Standardeinstellungen zu bekommen, den Stromverbrauch zu reduzieren und gleichzeitig zu verbessern Leistung (reale Leistung, die Sie mit Ihren Augen und Fingern spüren, nicht mit Synthetik Werkzeuge).
Irgendwann wollte ich ein einfach abstimmbares Gerät, damit die Leute auf einfache Weise mit der Leistung herumspielen können. So wurde Fastlane geboren :). Die Logik ähnelt in gewisser Weise der Funktionsweise von Honda VTEC: Spielen Sie mit den Timings ab einem bestimmten Schwellenwert. Mit einem einfachen Schalter und einem variablen Schwellenwert könnte man also eine direktere und aggressivere CPU-Frequenzskalierung erreichen. Je nach Systemauslastung wird es früher oder später aktiviert, wobei Ziellasten umgangen werden. Es ist vollständig mit HMP kompatibel und kann pro Cluster entsprechend den Bedürfnissen der Benutzer optimiert und für jedes Gerät, auf dem es ausgeführt wird, fein abgestimmt werden.
Welche integrierten Mechanismen oder Optimierungen, die OEMs anbieten, gefallen Ihnen bzw. nicht? dh Qualcomms Input-Boost.
Einige Userspace-Boosts und andere optimierbare Einstellungen, die in HALs (Hardware Abstraction Layers), hartcodierten Framework-Sachen usw. festgelegt sind, können manchmal störend sein. Natürlich sind Kernel-Entwickler dafür bekannt, einige dieser Probleme zu umgehen. Auf dem Nexus 5 haben die meisten von uns beispielsweise mpdecision abgeschafft und einen benutzerdefinierten Hotplug installiert – wir hatten damals blu_plug installiert. Einige andere Geräte hatten ein schlechtes Wärmemanagement und eine benutzerdefinierte Wärmekontrolle mit Sysfs für Temperaturniveaus, Abhilfehäufigkeit usw. Einige neuere Geräte verfügen über strenge Richtlinien zum Akku, zum Herausziehen von Kernen und anderen Dingen auf „niedrigem Niveau“, die keinen wirklichen Nutzen bei der Gerätenutzung gebracht haben. Tatsächlich hat es manchmal sogar das Benutzererlebnis beeinträchtigt, sodass es notwendig war, die CTL- und BCL-Technologien einzudämmen.
Ich erinnere mich auch daran, die Verschlüsselung in Geräten entfernt zu haben, als das überhaupt möglich war. All die Änderungen, die SELinux-Iterationen mit sich brachten, führten dazu, dass frühere Hacks anders funktionierten... Einige aktuelle Android-Sicherheitsänderungen stellen eine ständige Herausforderung dar. Dazu gehört AVB (einige Teile sind meist als dm-verity bekannt). Einige andere Änderungen führten zu Einschränkungen für Tunables und SYSFS-Orte, die verschoben werden mussten, da wir keinen Zugriff mehr auf die gleichen Orte haben wie zuvor. Die meisten dieser Einschränkungen sind für Standard-ROMs relevanter (in denen ich den Großteil meiner Arbeit erledige). Normalerweise ebnet es den Weg und macht es einfacher, wenn es um benutzerdefinierte ROMs geht (wo die Einschränkungen geringer sind).
Bei neueren SoCs wie dem Qualcomm Snapdragon 820 und 835 haben einige OEMs einige Verbesserungen aus dem Userspace hinzugefügt, die willkommen sind und blinde Flecken im System beseitigen. Nicht alle OEM-Sachen sind schlecht. Wenn es um Kernel-Quellen geht, gilt: Je sauberer und dokumentierter die Quelle, desto besser.
Welche weiteren Funktionen möchten Sie integrieren? Zum Beispiel erweiterte Farbsteuerung usw.
Normalerweise füge ich keine Dinge hinzu, die ich nicht persönlich verwende oder die ich nicht nützlich finde. Zu den Dingen, die ich neben blu_active gerne mache, gehören Architekturoptimierungen und -korrekturen, Krypto-Updates, IO-Planung und anderes Speicher-/Dateisystem-Extras, KCAL, USB-Schnellladung, Vibrationsstärke, Batterie-/Benachrichtigungs-LED-Kontrolle, Wakelock-Blocker, WireGuard, usw. Ich baue immer mit einer benutzerdefinierten Build-Toolchain, wie ich bereits sagte.
Welche Testmethode verwenden Sie für Ihren Kernel? Verwenden Sie Benutzerberichte, Benchmarks oder andere benutzerdefinierte Routinen?
Ich besitze jedes Telefon, für das ich entwickle, daher werden alle Änderungen immer von mir getestet. Da ich täglich über einen längeren Zeitraum jedes Gerät fahre, sollte alles, was ich für mich nicht geeignet finde, auch nicht für andere geeignet sein. Wenn ich einen Build öffentlich veröffentliche, wurde er bereits von mir und einigen anderen Personen, denen ich vertraue, dass sie nützliches Feedback liefern, zahlreichen Tests unterzogen. Ich weiß, dass es manchen Benutzern manchmal langweilig wird, wenn ständig alles so funktioniert, wie es sollte, aber ich lege vor allem Wert auf Stabilität: Ich versetze mich immer in die Lage eines Benutzers.
Ich orientiere mich an einem realen Anwendungsfall, nicht an synthetischen Tests. Diese Art von Software ist für Menschen gemacht, nicht für Maschinen im Backoffice. Der Startpunkt ist in jeder Hinsicht immer besser als die Standarderfahrung, aber ich schätze den neuesten Antutu-Highscore nicht so sehr. Meine Kernel können auf diese Art von Benchmark abgestimmt werden, aber das ist nicht mein Endziel. Ich schätze einige Benchmarks, die direkter sind, wie zum Beispiel IO-Speichertests. Sie können beispielsweise eine schnelle Möglichkeit bieten, einige kürzlich vorgenommene Änderungen geltend zu machen.
Ich führe meine Tests mit Standard-ROMs durch, damit ich eine stabile Basis für die Dinge habe. Ich mache benutzerdefinierte Builds für benutzerdefinierte ROMs, aber aufgrund der Volatilität benutzerdefinierter ROMs mit zusätzlichen Extras, Nightlies und sogar Implementierungsunterschiede bei einigen Funktionen, es ist unmöglich, sie alle abzudecken und allen die richtige Unterstützung zu bieten. Leider.
Manchmal erstelle ich auch Beta-Builds, um etwas Bestimmtes zu testen oder wenn ich Builds für Beta-ROMs oder Entwicklervorschauen starte. Ich habe das auf den Nexus- und OnePlus-Geräten gemacht, die Leute testen manchmal gerne Dinge aus :)
Schauen Sie sich Teil 2 an: F2FS, EAS und Tipps für angehende Kernel-Entwickler