No merge window desta terça-feira (5 de agosto de 2025), Linus Torvalds integrou o pull request de Russell King que “fecha a porta” do Coresight na árvore arch/arm. A alteração — identificada no commit 6bcdbd62bd56 — elimina por completo o arquivo arch/arm/include/asm/cti.h (160 linhas), marcando o fim do suporte a essa infraestrutura de rastreamento em processadores ARM de 32 bits. Para quem acompanha o desenvolvimento do Linux kernel ARM Coresight, trata-se de mais um capítulo do esforço contínuo de simplificação do código-fonte. Confira o que muda e por que isso é uma boa notícia.
O que era o Coresight?
ARM Coresight é um conjunto de blocos de hardware que permite depuração (debug) e rastreamento (trace) finos diretamente no System-on-Chip. Ele expõe trilhas de execução, eventos e dados de desempenho, ajudando engenheiros de silício e desenvolvedores de firmware a diagnosticar problemas em tempo real. Na era dos chips de 32 bits, essas interfaces faziam sentido para validar o hardware; porém, o ecossistema migrou quase totalmente para ARMv8+ (64 bits), onde o Coresight continua disponível por meio dos drivers genéricos em drivers/hwtracing/coresight/.
Para entender a transição, vale relembrar que o suporte específico de arch/arm — introduzido há mais de uma década — exigia headers e glue code únicos para lidar com o Cross-Trigger Interface (CTI). Esse material tornou-se redundante conforme os desenvolvedores consolidaram a camada genérica que hoje atende tanto a arquitetura arm64 quanto a outros subsistemas de rastreamento.
(Documentação técnica do Coresight pode ser consultada no site da Arm).
Por que remover código é um avanço?
- Redução da complexidade
Cada linha a menos significa um kernel mais enxuto. Com a eliminação do cabeçalhocti.h, desaparece também toda a lógica de compatibilidade que só fazia sentido para placas antigas. Menos ifs condicionais resultam em build times menores e revisões de código mais simples. - Manutenção facilitada
Desenvolvedores não precisam mais manter caminhos de código exclusivos para 32 bits, liberando energia para aprimorar o suporte a SoCs modernos e a arquiteturas emergentes, como RISC-V. O próprio Russell King destacou que “código legado sem usuários reais apenas atrapalha a evolução”. - Menos superfícies de bugs
Componentes raramente exercitados tendem a acumular falhas silenciosas. Ao removê-los, corta-se um elo potencial de vulnerabilidades — algo crítico para quem se preocupa com segurança de baixo nível. - Foco em tecnologias atuais
Em 2025, a maioria dos dispositivos comerciais baseados em ARM roda kernels 64 bits. Manter recursos iguais em ambas as arquiteturas custava tempo que agora pode ser investido em melhorias como perf events, BPF e novos tracers.
O que muda para desenvolvedores e usuários?
Se você ainda utiliza um sistema embarcado baseado em ARMv7 que dependia do Coresight, precisará permanecer em versões antigas do kernel ou migrar para ferramentas de rastreamento genéricas. Para a esmagadora maioria — distros de servidor, smartphones, tablets e SBCs recentes — nada muda: o Coresight permanece funcionando via drivers/hwtracing nas compilações arm64.
Para quem mantém forks customizados, a remoção simplifica o rebase: não será mais necessário ajustar patches que tocavam em arch/arm/include/asm/cti.h. Já para mantenedores de toolchains e plataformas CI, espera-se pequena economia de tempo de compilação e testes.
Conclusão
A retirada do ARM Coresight da árvore arch/arm simboliza a maturidade do Linux Kernel em deixar para trás dependências que já cumpriram seu papel. Ao enxugar seu coração, o kernel abre espaço para inovações e garante que os recursos de debug continuem relevantes no mundo predominante dos 64 bits.
