Recientemente entrevistamos a eng.stk, el desarrollador del kernel blu_spark. En esta parte le preguntamos sobre sus orígenes y labor de desarrollo.
Recientemente tuve la oportunidad de entrevistar al miembro senior de XDA. eng.stk, desarrollador del kernel blu_spark. Está disponible en muchos dispositivos en nuestros foros, incluidos Nexus 5, OnePlus 3/T y OnePlus 5T. En esta parte, le preguntamos a eng.stk sobre sus orígenes en el desarrollo y cómo desarrolla el kernel blu_spark.
Primero, preséntate a ti mismo y a tu núcleo. ¿Cómo se diferencia su núcleo de la competencia? ¿Cuál es su filosofía de diseño para los cambios del kernel y cómo los realiza?
Soy eng.stk y estoy presente en XDA desde 2010. La mayoría de ustedes me conocen por mis proyectos code_blue y blu_spark :)
Comencé en XDA escribiendo algunos scripts y herramientas diversas, trucos de marco. También he hecho muchos temas... Durante mi estancia aquí también he colaborado directamente en algunos proyectos como Purity ROM, Universal Kernel Manager, Kernel Adiutor y más recientemente Magisk y
AlambreGuardia Sólo para nombrar unos pocos. Últimamente también he estado trabajando en TWRP (especialmente en dispositivos OnePlus), módulos Magisk y otras herramientas/trucos. [que son] útiles durante el ciclo de vida de mis proyectos del kernel (algunas cosas fueron al Portal XDA si mal no recuerdo) correctamente). El kernel blu_spark comenzó a convertirse no solo en un kernel, sino en una experiencia integral entre kernel, cadenas de herramientas, recuperación, temas, herramientas, scripts, etc. Pero el trabajo del núcleo es lo que más disfruto y lo que me motiva.Siempre disfruté pirateando y creando algunos códigos/scripts cuando tuve la oportunidad (desarmar juguetes electrónicos y codificación básica en el Commodore 64 de mi primo fue divertido). Para mí, la codificación no es un medio para lograr un fin, sino simplemente una herramienta como otras para lograr un propósito definido. La mayoría de mis cosas más serias y los fundamentos de mi trabajo los hice cuando descubrí Linux durante mi adolescencia o principios de los veinte. Más tarde, en algún momento de la universidad, Android fue el siguiente paso lógico para mí: en realidad, el sueño de un manitas, donde se podía jugar mucho con el hardware o el software.
Las mejores palabras para describir blu_spark son optimización y estabilidad. Las personas que lo utilizan saben que pueden confiar en él. Las compilaciones de mi kernel son un tanto "restringidas" en el sentido de que tiendo a no eliminar algunas cosas disponibles de fábrica, manteniendo todo opcional para que la gente pueda elegir. No me gusta agregar demasiadas cosas, solo cambio o agrego lo que considero mejor para cada campo. El controlador de frecuencia de la CPU, el programador de IO, los protocolos de red, los sistemas de archivos, etc., o modifique algunos parámetros ajustables para algunos parámetros determinados o actualice algunos controladores para obtener el mejor resultado posible. También construyo cadenas de herramientas personalizadas (de Linaro, una versión increíble de GCC), principalmente para aprovechar al máximo la arquitectura.
En pocas palabras, la mayoría de las personas saben que están en blu_spark desde el momento en que actualizan el kernel en el dispositivo. Siempre estoy buscando cosas nuevas y formas de brindar la mejor UX posible. Sin peligro.
¡Cuéntanos sobre tu gobernador blu_active! ¿Qué es, qué hace y por qué es especial?
Sé que la gente a veces confunde blu_active con blu_spark. blu_active es sólo una pequeña parte en comparación con el resto [del trabajo] que hago.
Básicamente, el gobernador de la CPU toma decisiones para hacer que las frecuencias de la CPU aumenten o disminuyan, según las necesidades del sistema. El gobernador ha tenido varios cambios y mutaciones desde que inició. Como todo lo que hago, necesitaba algo que satisficiera mis necesidades. Está basado en mi gobernador favorito, el gobernador interactivo. Al principio solo le puse algunas cosas preliminares, pero luego comencé a agregar algunas otras cosas, como actualizaciones de CAF o lógica que había visto en otros gobernadores y que encuentro útiles. También agregué compatibilidad con HMP y algunas otras ventajas.
La última versión se basa en la rama Android Linux 4.4 de Google, con algunas correcciones upstream y CAF también, pero mucho más sencilla que antes. Simplemente usa lo que tienes al máximo y elimina lo que no tienes. Siempre trato de obtener una mejor batería que con la configuración original, reduciendo el consumo, mientras trato de mejorar rendimiento (rendimiento de la vida real, el que se siente con los ojos y los dedos, no con sintéticos herramientas).
En un momento dado, quería un sintonizable simple para que la gente pudiera jugar con el rendimiento de una manera sencilla. Así nació Fastlane :). La lógica es algo similar a la forma en que funciona Honda VTEC: jugar con tiempos a partir de un umbral determinado. Entonces, con un simple interruptor y un valor de umbral variable, las personas podrían tener un escalado de frecuencia de CPU más directo y agresivo. Haciéndolo ingresar tarde o temprano según la carga del sistema, evitando las cargas objetivo. Es totalmente compatible con HMP y se puede modificar por clúster según las necesidades de las personas y ajustarse con precisión para cada dispositivo en el que se ejecuta.
¿Qué mecanismos integrados o ajustes le gustan o no le gustan que ofrecen los OEM? es decir, el impulso de entrada de Qualcomm.
Algunas mejoras del espacio de usuario y otros ajustes que se configuran en HAL (capas de abstracción de hardware), elementos de marco codificados, etc., a veces pueden resultar molestos. Por supuesto, se sabe que los desarrolladores del kernel solucionan algunos de estos problemas. En el Nexus 5, por ejemplo, la mayoría de nosotros nos deshicimos de mpdecision y obtuvimos un hotplug personalizado; teníamos blu_plug implementado en ese momento. Algunos otros dispositivos tenían una mala gestión térmica y un control térmico personalizado con sysfs para niveles de temperatura, frecuencia de mitigación, etc. Algunos dispositivos más recientes tienen algunas políticas estrictas sobre la batería, la desconexión de núcleos y otras cosas en "niveles bajos" que no generaron una ganancia real en el uso del dispositivo. De hecho, a veces incluso arruinaba la experiencia del usuario, por lo que era necesario controlar las tecnologías CTL y BCL.
También recuerdo haber eliminado el cifrado en los dispositivos cuando eso existía, todos los cambios en las iteraciones de SELinux introdujeron cambios que hicieron que los hacks anteriores funcionaran de una manera diferente... Algunos cambios recientes de seguridad de Android son un desafío constante. Estos incluyen AVB (algunas partes se conocen principalmente como dm-verity). Algunos otros cambios han impuesto restricciones a los lugares sintonizables y sysfs que tuvieron que moverse porque no tenemos acceso a los mismos lugares que teníamos antes. La mayoría de estas restricciones son más relevantes para las ROM estándar (en las que hago la mayor parte de mi trabajo), normalmente allana el camino y lo hace más fácil cuando se trata de ROM personalizadas (donde las restricciones son menores).
En SoC recientes como Qualcomm Snapdragon 820 y 835, algunos OEM han agregado algunas mejoras desde el espacio de usuario que son bienvenidas y abordan puntos ciegos en el sistema; no todas las cosas OEM son malas. Cuando se trata de fuentes del kernel, cuanto más limpia y documentada esté la fuente, mejor.
¿Qué otras características te gustaría incluir? Como control de color avanzado, etc.
Normalmente no incluyo cosas que no uso personalmente o que no encuentro útiles. Las cosas que me gusta hacer, además de blu_active, incluyen optimizaciones y correcciones de arquitectura, actualizaciones de elementos criptográficos, programación de IO y otras extras de almacenamiento/sistema de archivos, KCAL, carga rápida USB, intensidad de vibración, control LED de batería/notificación, bloqueadores Wakelock, WireGuard, etc. Siempre construyo con una cadena de herramientas de compilación personalizada, como dije antes.
¿Qué metodología de prueba utiliza para su kernel? ¿Utiliza informes de usuario, puntos de referencia o alguna otra rutina personalizada?
Soy propietario de todos los teléfonos para los que desarrollo, por lo que cualquier cambio siempre se prueba por mi cuenta. Dado que conduzco diariamente todos los dispositivos durante un largo período de tiempo, cualquier cosa que encuentre que no es adecuada para mí, no debería serlo para nadie más. Cuando publico públicamente una compilación, ya ha sido sometida a muchas pruebas por mi parte y por otras personas en las que confío para brindar comentarios útiles. Sé que a veces algunos usuarios se aburren de tener todo funcionando como deberían constantemente, pero valoro la estabilidad por encima de todo: siempre me pongo en el lugar de un usuario en primer lugar.
Dirijo las cosas hacia un caso de uso de la vida real, no hacia pruebas sintéticas. Este tipo de software está hecho para humanos, no para máquinas en una oficina administrativa. El punto de partida siempre es mejor que la experiencia con las acciones, en todos los frentes, pero realmente no valoro mucho la última puntuación alta de Antutu. Mis núcleos se pueden ajustar a este tipo de punto de referencia, pero no es mi objetivo final. Valoro algunos puntos de referencia que son más directos, como las pruebas de almacenamiento IO, por ejemplo. Pueden ofrecer una forma rápida de afirmar algunos cambios realizados recientemente, por ejemplo.
Hago mis pruebas con ROM estándar para poder tener una base estable para las cosas. Hago compilaciones personalizadas para ROM personalizadas, pero debido a la naturaleza volátil de las ROM personalizadas con extras adicionales, nightlies e incluso diferencia de implementación en algunas características, es imposible cubrirlas todas y brindar soporte adecuado a todos, desafortunadamente.
A veces también creo compilaciones beta para probar algo específico o cuando lanzo compilaciones para ROM Beta o vistas previas para desarrolladores. Lo hice en los dispositivos Nexus y OnePlus, a la gente a veces le gusta probar cosas :)
Consulte la parte 2: F2FS, EAS y consejos para aspirantes a desarrolladores de kernel