Em uma das discussões mais acaloradas e estratégicas dos últimos tempos na lista de mailing do Kernel Linux, Linus Torvalds foi categórico ao rejeitar a proposta de inclusão do LTTng (Linux Trace Toolkit: next generation) como um subsistema paralelo de tracing no kernel. O tema, que envolve nomes de peso como Mathieu Desnoyers (Efficios), Steven Rostedt (Google/Kernel.org), Greg Kroah-Hartman, Christoph Hellwig, Masami Hiramatsu, Peter Zijlstra, Ingo Molnar e Thomas Gleixner, expõe as tensões, desafios e princípios centrais que regem o desenvolvimento do maior projeto código aberto do mundo.
A discussão, desencadeada em julho de 2025, gira em torno da ideia de um “bulk upstreaming” do LTTng — ou seja, sua inclusão massiva e praticamente intocada dentro do kernel, coexistindo com ferramentas já existentes, como ftrace e perf. Linus Torvalds deixou claro: “I am NOT interested in just having two different tracing models”. Para ele, aceitar dois sistemas de tracing separados, com buffers e interfaces disjuntas, seria repetir décadas de fragmentação sem avanços reais em unificação e manutenção. A exigência é simples e irredutível: só haverá lugar para o LTTng se houver infraestrutura compartilhada, unificação incremental e provas concretas de que tal integração é possível — ou seja, “Show me the code“.
O LTTng e a importância do tracing no Kernel Linux
Ferramentas de tracing são essenciais para a observabilidade, depuração e otimização de desempenho em sistemas modernos. No contexto do Kernel Linux, onde o desempenho e a previsibilidade são críticos para milhares de empresas, data centers e dispositivos, ter mecanismos avançados de tracing significa a diferença entre um sistema robusto e um cenário de bugs difíceis de diagnosticar.
O LTTng destaca-se como uma das soluções de tracing mais poderosas, amplamente utilizada em ambientes corporativos e sistemas embarcados. Desenvolvido inicialmente por Mathieu Desnoyers e mantido pela Efficios, ele se tornou referência para análise de desempenho e depuração de sistemas complexos, oferecendo tracing de eventos em espaço de usuário e kernel, ring buffers eficientes, filtragem avançada e integração com ferramentas de visualização. Contudo, sua arquitetura, por anos, permaneceu separada do ecossistema principal do Kernel Linux.
Tracing no Linux: ferramentas para depuração e otimização de desempenho
Desde o início do kernel, tracing foi tratado como uma função essencial, mas muitas vezes fragmentada. Ferramentas como ftrace e perf se consolidaram como as soluções nativas, permitindo coleta detalhada de eventos, análise de latência, profiling de CPU e rastreamento de chamadas de sistema.
ftrace, mantido por Steven Rostedt, é o sistema de tracing principal do kernel, integrado desde 2008. Ele oferece uma interface flexível para registrar eventos, criar tracepoints e interagir com outros subsistemas de monitoramento. Já o perf, desenvolvido por Ingo Molnar e outros, foca em profiling de desempenho e análise de eventos de hardware, sendo crucial para engenheiros de performance.
A existência dessas ferramentas não impediu o surgimento do LTTng, que evoluiu paralelamente, sempre defendendo uma abordagem mais modular e flexível para tracing. No entanto, a fragmentação é visível: cada sistema tem seus próprios ring buffers, APIs, formatos de eventos e modelos de controle de acesso. É esse cenário que alimenta o debate atual sobre a necessidade (ou não) de convergência.
O LTTng: uma solução robusta e popular fora do kernel
O LTTng construiu uma reputação de excelência fora da árvore oficial do kernel. Sua capacidade de capturar grandes volumes de eventos com overhead mínimo, somada à possibilidade de customização via tracepoints dinâmicos e filtros avançados, faz dele uma escolha privilegiada em contextos onde a precisão e o detalhamento são indispensáveis.
Empresas de tecnologia, setores automotivo, telecomunicações e sistemas embarcados frequentemente dependem do LTTng para análises forenses, debug de bugs críticos e identificação de gargalos de performance. A ferramenta permite rastrear desde o boot do sistema até interações sofisticadas entre múltiplos processos e dispositivos, atuando em camadas onde outras soluções esbarram em limitações técnicas ou de integração.
Apesar de toda essa robustez, o LTTng sempre esbarrou em uma barreira significativa: a ausência de uma integração upstream. Isso significa que, para utilizá-lo, é necessário aplicar patches, manter módulos fora da árvore principal e aceitar o risco de incompatibilidade a cada novo ciclo de desenvolvimento do kernel.
A posição inabalável de Linus Torvalds: unificação ou exclusão
Linus Torvalds, criador e mantenedor supremo do Kernel Linux, é conhecido por sua abordagem pragmática e por rejeitar soluções que aumentem a complexidade desnecessariamente. Sua recusa ao “bulk upstreaming” do LTTng é um exemplo cristalino de seu estilo de liderança.
Para Linus, aceitar dois sistemas de tracing com buffers, interfaces e APIs desunificadas é abrir a porta para a fragmentação, dificultando manutenção, depuração e evolução do kernel. Ele argumenta que “décadas de falta de acordo em modelos comuns provam que a unificação nunca aconteceu”. Ou seja, permitir dois sistemas paralelos só atrasaria ainda mais qualquer tentativa de convergência e aumentaria o peso sobre os mantenedores e desenvolvedores.
Seu ponto central: ou se constrói uma infraestrutura comum, ou não se constrói nada. Ele vai além, dizendo que se alguém realmente acredita que a unificação é possível, deve começar pequeno, mostrando código, provando na prática e evoluindo de forma incremental — não por meio de um grande patch set que apenas duplica funcionalidades existentes.
“Não estou interessado em ter dois modelos de tracing diferentes”
No cerne da recusa está o princípio de que features do kernel devem ser universais, não optativas e paralelas. Linus Torvalds é explícito ao afirmar que não quer ver “two different and disjoint trace buffers” nem “two different and disjoint trace interfaces”. Para ele, cada camada adicional de redundância é um convite a bugs, inconsistências e à temida “bit rot” (apodrecimento de código não mantido).
Se for absolutamente necessário manter dois modelos, Linus defende que um deles permaneça “out of tree” — ou seja, fora do código principal do kernel, como já ocorre com o LTTng atualmente. Essa decisão impõe um ônus considerável aos desenvolvedores do LTTng, que precisam constantemente adaptar sua base a mudanças internas do kernel, mas, do ponto de vista da coesão e manutenção do projeto principal, é uma posição que privilegia a sustentabilidade a longo prazo.
O ceticismo histórico: décadas de falta de unificação
A resistência de Linus Torvalds não é meramente teórica; ela se baseia em um histórico concreto de tentativas frustradas de unificação entre diferentes soluções de tracing. Por mais de vinte anos, projetos paralelos tentaram convergir — quase sempre sem sucesso duradouro. A “fusão” sugerida por defensores do LTTng nunca saiu do papel exatamente porque faltou o compromisso com uma infraestrutura realmente compartilhada.
Essa experiência histórica reforça o ceticismo de Linus em relação a grandes promessas de unificação “no futuro”. Ele exige resultados tangíveis, preferindo evoluções incrementais e provas de conceito sólidas à aposta em projetos “grandes demais para dar errado”.
A condição: infraestrutura compartilhada e desenvolvimento incremental
O único caminho para a aceitação do LTTng no Kernel Linux é a convergência real, começando pela criação de uma infraestrutura compartilhada. Isso significa adotar buffers comuns, APIs unificadas para controle e coleta de eventos, e, acima de tudo, evitar a duplicação de código e funcionalidades.
Linus propõe uma abordagem incremental, em que cada melhoria ou adição seja debatida, implementada, testada e, somente após comprovação, expandida. Esse método não apenas reduz o risco de quebras de compatibilidade, como também permite que a comunidade avalie o impacto real de cada mudança.
Ele resume sua exigência na famosa frase: “Show me the code.” — pedindo soluções concretas, e não apenas argumentos teóricos ou promessas de colaboração futura.
O debate e as implicações para o futuro do tracing no Linux
O impasse entre defensores do LTTng e a liderança do kernel evidencia questões profundas sobre inovação, manutenção e governança em grandes projetos de código aberto. Para muitos desenvolvedores, ter múltiplos sistemas de tracing no kernel permitiria flexibilidade e especialização. Para outros, representaria o início de uma fragmentação perigosa, capaz de comprometer o ritmo de desenvolvimento e a qualidade do código.
As decisões tomadas agora vão repercutir por anos, impactando ferramentas de observabilidade, o fluxo de trabalho de engenheiros de performance, e a própria forma como bugs críticos são diagnosticados e corrigidos em sistemas Linux em produção.
Consequências de ter múltiplos subsistemas de tracing no kernel
Aceitar múltiplos subsistemas de tracing traria implicações diretas para desenvolvedores e usuários. Entre os principais riscos estão:
- Complexidade de manutenção: Duas bases de código distintas aumentam o trabalho dos mantenedores.
- Inconsistência de APIs: Ferramentas e scripts que funcionam com um subsistema podem não ser compatíveis com outro.
- Confusão para usuários e desenvolvedores: Dúvidas sobre qual subsistema usar em diferentes cenários.
- Risco de bit rot: O subsistema menos utilizado tende a ser esquecido, acumulando bugs e falhas de segurança.
- Desperdício de recursos: Esforço duplicado para manter e evoluir funcionalidades semelhantes.
Por outro lado, uma infraestrutura compartilhada pode trazer sinergias, otimizações e garantir que todas as melhorias beneficiem o ecossistema como um todo.
O papel da prova de conceito: “Show me the code”
A cultura do Kernel Linux valoriza a prática sobre a teoria. O mantra “Show me the code” resume a postura de Linus e da maioria dos mantenedores: ideias e propostas são bem-vindas, mas só têm peso real quando acompanhadas de implementações testáveis.
Para o LTTng, isso significa que, para além dos debates filosóficos sobre arquitetura e governança, será preciso apresentar patches concretos, demonstrando a possibilidade de integração com os subsistemas existentes, sem criar duplicidade de buffers, APIs ou ferramentas.
Esse pragmatismo é o que mantém o kernel estável, eficiente e confiável, mesmo diante da enorme diversidade de interesses e demandas da comunidade global.
Governança de projetos open source: Linus Torvalds e a autoridade do mantenedor
O episódio é um lembrete do papel central de Linus Torvalds na governança do Kernel Linux. Sua autoridade não é absoluta, mas é amplamente respeitada e baseada em décadas de liderança, visão técnica e capacidade de tomar decisões difíceis.
A recusa em aceitar o LTTng nos moldes propostos reforça uma tradição do projeto: inovação é bem-vinda, mas nunca às custas da coesão, da clareza e da sustentabilidade a longo prazo. Linus Torvalds atua como guardião da integridade do kernel, equilibrando interesses individuais, pressão de empresas e as necessidades da base global de usuários.
O processo de tomada de decisão no desenvolvimento do Kernel Linux
Decisões sobre grandes mudanças no Kernel Linux são sempre fruto de intenso debate público, revisão por pares e testes extensivos. A lista de mailing é palco de negociações, divergências e, eventualmente, consenso. O episódio do LTTng é exemplar: por mais polêmica que seja a discussão, o foco permanece em manter a qualidade e o futuro do kernel.
A exigência por infraestrutura compartilhada não é mero capricho: é uma salvaguarda contra a fragmentação e a estagnação. Somente ao priorizar a convergência incremental é possível garantir que o Kernel Linux continue sendo referência em desempenho, estabilidade e inovação.
Conclusão: o LTTng e a visão de Linus para um kernel Linux coeso e eficiente
A recusa de Linus Torvalds em aceitar o LTTng como um subsistema paralelo de tracing sem infraestrutura compartilhada não é apenas uma questão técnica; é um manifesto em defesa de um Kernel Linux coeso, sustentável e eficiente. O episódio evidencia os desafios de evolução de grandes projetos de código aberto, onde inovação, legado e governança se entrelaçam de forma única.
Para desenvolvedores, engenheiros de performance e toda a comunidade Linux, o recado é claro: o caminho para a integração é a colaboração real, o pragmatismo e o respeito às lições aprendidas ao longo de décadas. O futuro do tracing no Linux dependerá da capacidade de unir esforços, compartilhar infraestrutura e evoluir de forma incremental — sem abrir mão dos princípios que fizeram do kernel o coração pulsante do software livre.
