Nous avons récemment interviewé eng.stk, le développeur du noyau blu_spark. Dans cette partie, nous l'interrogeons sur ses origines et son travail de développement.
J'ai récemment eu la chance d'interviewer un membre senior de XDA fra.stk, développeur du noyau blu_spark. Il est disponible sur de nombreux appareils sur nos forums, notamment le Nexus 5, le OnePlus 3/T et le OnePlus 5T. Dans cette partie, nous interrogeons eng.stk sur ses origines dans le développement et comment il développe le noyau blu_spark.
Alors d’abord, présentez-vous ainsi que votre noyau. Comment votre noyau se différencie-t-il de la concurrence? Quelle est votre philosophie de conception en matière de modifications du noyau et comment procédez-vous ?
Je m'appelle eng.stk et je suis sur XDA depuis 2010. La plupart d'entre vous me connaissent grâce à mes projets code_blue et blu_spark :)
J'ai commencé sur XDA en écrivant quelques scripts et divers outils, framework hacks. J'ai également fait beaucoup de thèmes... Durant mon séjour ici, j'ai également collaboré directement à certains projets comme Purity ROM, Universal Kernel Manager, Kernel Adiutor et plus récemment Magisk et WireGuard Juste pour en nommer quelques-uns. J'ai également fait du travail sur TWRP ces derniers temps (en particulier sur les appareils OnePlus), des modules Magisk et d'autres outils/hacks. [qui sont] utiles pendant le cycle de vie de mes projets de noyau (certains éléments sont allés sur le portail XDA si je me souviens bien) correctement). Le noyau blu_spark a commencé à devenir non seulement un noyau, mais une expérience complète entre le noyau, les chaînes d'outils, la récupération, les thèmes, les outils, les scripts, etc. Mais le travail sur le noyau est ce que j'apprécie le plus et ce qui me motive.
J'ai toujours aimé pirater et créer du code/des scripts lorsque j'en avais l'occasion (démonter des jouets électroniques et coder de base sur le Commodore 64 de mon cousin était amusant). Pour moi, le codage n’est pas un moyen mais juste un outil comme d’autres pour atteindre un objectif défini. La plupart de mes tâches les plus sérieuses et les fondements de mon travail ont été réalisés lorsque j'ai découvert Linux à l'adolescence/au début de la vingtaine. Plus tard, quelque part à l'époque universitaire, Android était la prochaine étape logique pour moi: un véritable rêve de bricoleur, où le matériel ou les logiciels pouvaient être utilisés avec beaucoup de choses.
Les meilleurs mots pour décrire blu_spark sont optimisation et stabilité. Les gens qui l'utilisent savent qu'ils peuvent compter sur lui. Mes versions de noyau sont quelque peu « stockées », dans le sens où j'ai tendance à ne pas supprimer certains éléments disponibles immédiatement, en gardant tout facultatif afin que les gens puissent choisir. Je n'aime pas ajouter trop de choses, je change ou ajoute simplement ce que je considère comme le meilleur pour chaque domaine donné. Le pilote de fréquence CPU, le planificateur d'E/S, les protocoles réseau, les systèmes de fichiers, etc. ou modifiez certains paramètres pour certains paramètres donnés ou en amont certains pilotes pour le meilleur résultat possible. Je crée également des chaînes d'outils sur mesure (de Linaro, une superbe version de GCC), principalement pour tirer le meilleur parti de l'architecture.
En fin de compte, la plupart des gens savent qu'ils sont sur blu_spark à partir du moment où ils flashent le noyau sur l'appareil. Je suis toujours à la recherche de nouveautés et de moyens d'offrir la meilleure UX possible. Sans encombre.
Parlez-nous de votre régulateur blu_active! Qu'est-ce que c'est, à quoi ça sert et pourquoi est-ce spécial ?
Je sais que les gens confondent parfois blu_active avec blu_spark. blu_active n'est qu'une petite partie par rapport à tout le reste [du travail] que je fais.
Le gouverneur du processeur prend essentiellement la décision d'augmenter ou de diminuer les fréquences du processeur, en fonction des besoins du système. Le gouverneur a connu plusieurs changements et mutations depuis ses débuts. Comme tout ce que je fais, j’avais besoin de quelque chose qui réponde à mes besoins. Il est basé sur mon gouverneur préféré, le gouverneur interactif. Au début, j'ai juste mis quelques éléments en amont, mais j'ai ensuite commencé à ajouter d'autres éléments, comme des mises à jour du CAF ou une logique que j'avais vue dans d'autres gouverneurs et que je trouvais utiles. J'ai également ajouté la compatibilité HMP et quelques autres goodies.
La dernière itération est basée sur la branche Android Linux 4.4 de Google, avec également quelques correctifs en amont et CAF, mais beaucoup plus légère qu'auparavant. Utilisez simplement ce que vous avez au maximum, supprimez ce que vous n'avez pas. J'essaie toujours d'obtenir une meilleure batterie qu'avec les paramètres d'origine, en réduisant la consommation, tout en essayant d'améliorer performance (performance réelle, celle que vous ressentez avec vos yeux et vos doigts, pas avec des synthétiques) outils).
À un moment donné, je voulais un réglage simple pour que les gens puissent jouer avec les performances de manière simple. C'est ainsi qu'est né Fastlane :). La logique est un peu similaire au fonctionnement du Honda VTEC: jouer avec les timings à partir d'un seuil donné. Ainsi, avec un simple commutateur et une valeur de seuil variable, les utilisateurs pourraient bénéficier d'une mise à l'échelle de la fréquence du processeur plus directe et plus agressive. Le faire entrer tôt ou tard en fonction de la charge du système, en contournant les charges cibles. Il est entièrement compatible avec HMP et peut être modifié par cluster en fonction des besoins des utilisateurs, finement réglé pour chaque appareil sur lequel il s'exécute.
Quels mécanismes ou ajustements intégrés aimez-vous/n’aimez-vous pas et proposés par les OEM? c'est-à-dire l'augmentation des entrées de Qualcomm.
Certaines améliorations de l'espace utilisateur et autres paramètres définis dans les HAL (Hardware Abstraction Layers), les éléments de framework codés en dur, etc., peuvent parfois être ennuyeux. Bien sûr, les développeurs du noyau sont connus pour contourner certains de ces problèmes. Sur le Nexus 5, par exemple, la plupart d'entre nous se sont débarrassés de mpdecision et ont obtenu un hotplug personnalisé - nous avions blu_plug en place à l'époque. Certains autres appareils avaient une mauvaise gestion thermique et un contrôle thermique personnalisé avec sysfs pour les niveaux de température, la fréquence d'atténuation, etc. Certains appareils plus récents ont des politiques strictes en matière de batterie, de débranchement des cœurs et d'autres éléments à des "niveaux bas" qui n'ont pas apporté de réel gain d'utilisation de l'appareil. En fait, cela gâchait même parfois l’expérience utilisateur, il était donc nécessaire d’apprivoiser les technologies CTL et BCL.
Je me souviens également de la suppression du cryptage dans les appareils lorsque c'était une chose, tous les changements dans les itérations SELinux ont introduit des changements qui ont fait fonctionner les hacks précédents d'une manière différente... certaines modifications récentes en matière de sécurité Android constituent un défi constant. Ceux-ci incluent AVB (certaines parties sont principalement connues sous le nom de dm-verity). Certains autres changements ont introduit des restrictions pour les emplacements des paramètres réglables et sysfs qui ont dû être déplacés car nous n'avons pas accès aux mêmes emplacements qu'avant. La plupart de ces restrictions sont plus pertinentes pour les ROM d'origine (dans lesquelles je fais la plupart de mon travail). Normalement, elles ouvrent la voie et facilitent la tâche lorsqu'il s'agit de ROM personnalisées (où les restrictions sont moindres).
Dans les SoC récents comme les Qualcomm Snapdragon 820 et 835, certains OEM ont ajouté des améliorations de l'espace utilisateur qui sont les bienvenues et s'attaquent aux angles morts du système. Tous les éléments OEM ne sont pas mauvais. En ce qui concerne les sources du noyau, plus la source est propre et documentée, mieux c'est.
Quelles autres fonctionnalités aimez-vous inclure? Tels que le contrôle avancé des couleurs, etc.
Normalement, je n'inclus pas les éléments que je n'utilise pas personnellement ou que je ne trouve pas utiles. Les choses que j'aime faire, outre blu_active, incluent des optimisations et des correctifs d'architecture, des mises à jour de contenu cryptographique, la planification d'E/S et autres. goodies de stockage/système de fichiers, KCAL, charge rapide USB, force de vibration, contrôle LED de la batterie/notification, bloqueurs Wakelock, WireGuard, etc. Je construis toujours avec une chaîne d'outils de construction personnalisée, comme je l'ai dit plus tôt.
Quelle méthodologie de test utilisez-vous pour votre noyau? Utilisez-vous des rapports utilisateur, des benchmarks ou d'autres routines personnalisées ?
Je possède tous les téléphones pour lesquels je développe, donc tout changement est toujours testé par moi. Étant donné que je conduis quotidiennement chaque appareil pendant une longue période, tout ce que je trouve qui ne me convient pas ne devrait convenir à personne d'autre. Lorsque je publie publiquement une version, elle a déjà fait l'objet de nombreux tests de ma part et de la part d'autres personnes en qui j'ai confiance pour fournir des commentaires utiles. Je sais que parfois certains utilisateurs s'ennuient de voir constamment tout fonctionner comme il se doit, mais j'apprécie avant tout la stabilité: je me mets toujours à la place d'un utilisateur en premier lieu.
J'oriente les choses vers un cas d'utilisation réel, pas vers des tests synthétiques. Ce type de logiciel est conçu pour les humains, pas pour les machines d’un back-office. Le point de départ est toujours meilleur que l’expérience boursière, sur tous les fronts, mais je n’apprécie pas vraiment le dernier score élevé d’Antutu. Mes noyaux peuvent être adaptés à ce type de référence, mais ce n'est pas mon objectif final. J'apprécie certains benchmarks plus directs, comme les tests de stockage IO par exemple. Ils peuvent donner un moyen rapide de faire valoir certains changements récemment effectués par exemple.
Je fais mes tests avec des ROM d'origine afin de pouvoir avoir une base de référence stable pour les choses. Je fais des versions personnalisées pour les ROM personnalisées, mais en raison de la nature volatile des ROM personnalisées avec des extras supplémentaires, des soirées et même différence d'implémentation sur certaines fonctionnalités, il est impossible de toutes les couvrir et d'apporter un support approprié à tout le monde, malheureusement.
Je crée aussi parfois des versions bêta pour tester quelque chose de spécifique ou lorsque je lance des versions sur des ROM bêta ou des aperçus de développeur. Je l'ai fait sur les appareils Nexus et OnePlus, les gens aiment parfois tester des trucs :)
Découvrez la partie 2: F2FS, EAS et conseils pour les futurs développeurs de noyau