Entrevistamos recentemente eng.stk, o desenvolvedor do kernel blu_spark. Nesta parte perguntamos-lhe sobre as suas origens e trabalho de desenvolvimento.
Recentemente tive a oportunidade de entrevistar o membro sênior do XDA eng.stk, desenvolvedor do kernel blu_spark. Está disponível em vários dispositivos em nossos fóruns, incluindo Nexus 5, OnePlus 3/T e OnePlus 5T. Nesta parte, perguntamos a eng.stk sobre suas origens no desenvolvimento e como ele desenvolve o kernel blu_spark.
Então, primeiro, apresente você e seu kernel. Como o seu kernel se diferencia da concorrência? Qual é a sua filosofia de design para mudanças no kernel e como você as faz?
Meu nome é eng.stk e estou no XDA desde 2010. A maioria de vocês me conhece dos meus projetos code_blue e blu_spark :)
Comecei no XDA escrevendo alguns scripts e ferramentas diversas, hacks de framework. Eu fiz muitos temas também... Durante meu tempo aqui também colaborei diretamente com alguns projetos como Purity ROM, Universal Kernel Manager, Kernel Adiutor e mais recentemente Magisk e WireGuard apenas para citar alguns. Ultimamente também tenho feito alguns trabalhos de TWRP (especialmente em dispositivos OnePlus), módulos Magisk e outras ferramentas/hacks [que são] úteis durante o ciclo de vida dos meus projetos de kernel (algumas coisas foram para o Portal XDA, se bem me lembro corretamente). O kernel blu_spark começou a se tornar não apenas um kernel, mas uma experiência completa entre kernel, conjuntos de ferramentas, recuperação, temas, ferramentas, scripts, etc. Mas o trabalho do kernel é o que mais gosto e o que me motiva.
Eu sempre gostei de hackear e criar alguns códigos/scripts quando tive a chance (desmontar brinquedos eletrônicos e codificação básica no Commodore 64 do meu primo foi divertido). Para mim, a codificação não é um meio para um fim, mas apenas uma ferramenta como outras para atingir um propósito definido. A maior parte das minhas coisas mais sérias e fundamentos do meu trabalho foram feitas quando descobri o Linux durante minha adolescência/vinte e poucos anos. Mais tarde, em algum momento da época da universidade, o Android foi o próximo passo lógico para mim: o sonho de um consertador, na verdade, onde hardware ou software poderiam ser usados muito.
As melhores palavras para descrever o blu_spark são otimização e estabilidade. As pessoas que o utilizam sabem que podem confiar nele. Minhas compilações de kernel são um tanto 'estocadas' de uma forma que eu tendo a não remover algumas coisas disponíveis da caixa, mantendo tudo opcional para que as pessoas possam escolher. Não gosto de acrescentar muitas coisas, apenas altero ou adiciono o que considero melhor para cada área. O driver de frequência da CPU, o agendador IO, os protocolos de rede, os sistemas de arquivos, etc. ou ajustam alguns ajustes para alguns parâmetros específicos ou upstream alguns drivers para o melhor resultado possível. Eu também construo toolchains customizados (do Linaro, uma versão incrível do GCC), principalmente para tirar o melhor proveito da arquitetura.
Resumindo, a maioria das pessoas sabe que está no blu_spark desde o momento em que atualiza o kernel no dispositivo. Estou sempre em busca de novidades e maneiras de oferecer a melhor UX possível. Com segurança.
Conte-nos sobre o seu governador blu_active! O que é, o que faz e por que é especial?
Eu sei que as pessoas às vezes confundem blu_active com blu_spark. blu_active é apenas uma pequena parte em comparação com todo o resto [do trabalho] que faço.
O governador da CPU basicamente toma decisões para aumentar ou diminuir as frequências da CPU, de acordo com as necessidades do sistema. O governador passou por diversas mudanças e mutações desde que começou. Como tudo o mais que faço, precisava de algo que atendesse às minhas necessidades. É baseado no meu governador favorito, o governador interativo. No início, apenas coloquei algumas coisas do upstream, mas depois comecei a adicionar outras coisas, como atualizações do CAF ou lógica que vi em outros governadores que considero úteis. Também adicionei compatibilidade com HMP e algumas outras vantagens.
A iteração mais recente é baseada no ramo Linux 4.4 Android do Google, com algumas correções upstream e CAF também, mas muito mais enxuta do que antes. Simplesmente use o que você tem ao máximo e remova o que não tem. Eu sempre tento obter uma bateria melhor do que com as configurações de estoque, reduzindo o consumo, enquanto tento melhorar desempenho (desempenho na vida real, aquele que você sente com os olhos e os dedos, não com sintético ferramentas).
A certa altura, eu queria um ajuste simples para que as pessoas pudessem brincar com o desempenho de uma forma simples. Foi assim que nasceu o Fastlane :). A lógica é um pouco semelhante à forma como o Honda VTEC funciona: brinque com os tempos a partir de um determinado limite. Assim, com uma simples mudança e um valor de limite variável, as pessoas poderiam ter um escalonamento de frequência de CPU mais direto e agressivo. Fazendo com que ele entre mais cedo ou mais tarde de acordo com a carga do sistema, contornando as cargas alvo. É totalmente compatível com HMP e pode ser ajustado por cluster de acordo com as necessidades das pessoas, ajustado para cada dispositivo em que é executado.
Quais mecanismos ou ajustes integrados você gosta/não gosta que os OEMs fornecem? ou seja, o aumento de entrada da Qualcomm.
Alguns aumentos de espaço do usuário e outros ajustes definidos em HALs (camadas de abstração de hardware), estruturas codificadas etc., às vezes podem ser irritantes. É claro que os desenvolvedores de kernel são conhecidos por contornar alguns deles. No Nexus 5, por exemplo, a maioria de nós se livrou do mpdecision e adquiriu um hotplug personalizado - tínhamos o blu_plug instalado na época. Alguns outros dispositivos tinham gerenciamento térmico ruim e controle térmico personalizado com sysfs para níveis de temperatura, frequência de mitigação, etc. Alguns dispositivos mais recentes têm políticas rígidas sobre bateria, desconexão de núcleos e outras coisas em “níveis baixos” que não proporcionaram um ganho real no uso do dispositivo. Na verdade, às vezes até arruinava a experiência do usuário, por isso foi necessário domar as tecnologias CTL e BCL.
Eu também me lembro de remover a criptografia em dispositivos quando isso existia, todas as mudanças nas iterações do SELinux introduziram mudanças que fizeram os hacks anteriores funcionarem de uma maneira diferente... algumas mudanças recentes de segurança do Android são um desafio constante. Isso inclui AVB (algumas partes são conhecidas principalmente como dm-verity). Algumas outras mudanças fizeram restrições para locais ajustáveis e sysfs que tiveram que ser movidos porque não temos acesso aos mesmos locais que tínhamos antes. A maioria dessas restrições são mais relevantes para ROMs de estoque (nas quais faço a maior parte do meu trabalho), normalmente abrem o caminho e facilitam quando se trata de ROMs customizadas (onde as restrições são menores).
Em SoCs recentes, como o Qualcomm Snapdragon 820 e 835, alguns OEMs adicionaram alguns aumentos no espaço do usuário que são bem-vindos e abordam pontos cegos no sistema, nem todas as coisas do OEM são ruins. Quando se trata do código-fonte do kernel, quanto mais limpo e documentado for o código-fonte, melhor.
Que outros recursos você gostaria de incluir? Como controle avançado de cores e assim por diante.
Normalmente não incluo coisas que não uso pessoalmente ou que não considero úteis. Coisas que gosto de fazer, além de blu_active, incluem otimizações e correções de arquitetura, atualizações de criptografia, agendamento de IO e outros itens de armazenamento / sistema de arquivos, KCAL, carga rápida USB, intensidade de vibração, controle de bateria / LED de notificação, bloqueadores Wakelock, WireGuard, etc. Eu sempre construo com um conjunto de ferramentas de construção personalizado, como disse anteriormente.
Qual metodologia de teste você usa para seu kernel? Você usa relatórios de usuários, benchmarks ou quaisquer outras rotinas personalizadas?
Eu possuo todos os telefones para os quais desenvolvo, portanto, quaisquer alterações são sempre testadas por mim. Como dirijo todos os dispositivos diariamente por um longo período de tempo, qualquer coisa que não seja adequada para mim não deveria servir para mais ninguém. Quando lanço publicamente uma compilação, ela já passou por muitos testes meus e de outras pessoas em quem confio para fornecer feedback útil. Sei que às vezes alguns usuários ficam entediados por ter tudo funcionando como deveria, mas valorizo a estabilidade acima de tudo: sempre me coloco no lugar do usuário em primeiro lugar.
Eu corro para um caso de uso da vida real, não para testes sintéticos. Esse tipo de software é feito para humanos, não para máquinas de back office. O ponto de partida é sempre melhor do que a experiência em ações, em todas as frentes, mas eu realmente não valorizo muito a pontuação mais alta do Antutu mais recente. Meus kernels podem ser ajustados para esse tipo de benchmark, mas esse não é meu objetivo final. Eu valorizo alguns benchmarks que são mais diretos, como testes de armazenamento de IO, por exemplo. Eles podem fornecer uma maneira rápida de afirmar algumas alterações feitas recentemente, por exemplo.
Eu faço meus testes com ROMs de estoque para poder ter uma base estável para as coisas. Eu faço compilações customizadas para ROMs customizadas, mas devido à natureza volátil das ROMs customizadas com extras adicionados, nightlies e até mesmo diferença de implementação em alguns recursos, é impossível cobrir todos eles e dar suporte adequado a todos, infelizmente.
Às vezes, também crio compilações beta para testar algo específico ou para quando lanço compilações para ROMs beta ou visualizações para desenvolvedores. Eu fiz isso nos dispositivos Nexus e OnePlus, às vezes as pessoas gostam de testar coisas :)
Confira a parte 2: F2FS, EAS e dicas para aspirantes a desenvolvedores de kernel