A tentativa de adicionar suporte ao Intel Gaudi3 ao Linux 6.19 durou poucas horas em público, mas vale como uma aula completa sobre como o kernel trata mudanças gigantes. O pacote enviado pela HabanaLabs (Intel) era ambicioso: quase 300 mil linhas de código para habilitar um novo acelerador de IA, com pilares técnicos como MMU v3, ODP (On-Demand Paging) e uma camada reforçada de segurança. Mesmo assim, o resultado foi um “não” do mantenedor do DRM, Dave Airlie, e o reagendamento do suporte para o Linux 6.20.
O gigante de 300 mil linhas
O pull request não era “só mais um driver”. Ele carregava, de uma vez, o fechamento do gap entre o estado atual do driver accel/habanalabs e o que seria necessário para o Gaudi3 funcionar de ponta a ponta no kernel principal. Isso inclui novas rotas de gerenciamento de memória com MMU v3 (uma arquitetura de MMU específica para o Gaudi3), suporte a paginação sob demanda via ODP, infraestrutura de segurança com bits de proteção e configuração, além de um bloco massivo de definições de registradores e interfaces com firmware.
Esse tipo de envio costuma ser o “final do funil”: anos de desenvolvimento interno (no caso, citado como 2021 a 2024) condensados em um conjunto que finalmente tenta virar upstream. E é aí que mora o risco.
Por que foi rejeitado?
O motivo imediato não foi uma discordância de direção técnica. Foi qualidade e processo.
Dave Airlie apontou que o pull request chegou tarde para entrar com segurança no ciclo do Linux 6.19, lembrando as regras do subsistema: suporte a hardware novo precisa passar por linux-next com antecedência, para absorver testes, revisões e interações com outros ramos antes do merge window. Em outras palavras, o relógio do kernel não perdoa.
Além do timing, a revisão inicial encontrou “bagunças” bem concretas, do tipo que acende alerta vermelho em qualquer maintainer:
- Artefatos e ajustes com cara de build interno, como mudanças em .clang-format que não deveriam “pegar carona” num PR de driver, e sinais de integração com ambiente fora da árvore principal.
- Trechos suspeitos no Makefile, incluindo tentativas de impor a configuração do módulo e referências a caminhos externos (o caso clássico de variável como OFED_PATH e uso de KBUILD_EXTRA_SYMBOLS), que são padrões típicos de integração corporativa, mas fora do esperado para o mainline.
- O ponto mais grave: reversões acidentais de trabalho upstream já aceito, como mudanças anteriores relacionadas a timeouts (por exemplo, conversões para secs_to_jiffies()). Isso sugere que a base interna usada para gerar o PR estava dessincronizada com o kernel atual, e ao “empilhar” o suporte ao Gaudi3 por cima, partes do trabalho comunitário acabaram desfeitas sem intenção.
Aqui entra a analogia da reforma da casa: imagine que você contratou uma equipe para construir uma ala nova gigante na sua casa, o suporte ao Gaudi3. Eles chegam com material e plantas, mas, ao começar a obra, sem querer começam a demolir janelas novas que você acabou de instalar na sala antiga, as correções upstream recentes. O inspetor da obra, Dave Airlie, manda parar: “voltem quando a planta estiver sincronizada com a casa de verdade”.
A resposta da Intel foi o comportamento certo
A reação da equipe da HabanaLabs, representada por Konstantin Sinyuk, foi direta e profissional: o pull request foi formalmente retirado (withdraw). Em vez de insistir ou “negociar exceção”, eles assumiram um plano de correção que é exatamente o que mantenedores querem ouvir: remover artefatos fora do padrão, rebater (rebase) o trabalho interno preservando o histórico upstream, auditar reverts não intencionais e testar contra o estado atual do drm-next, com um novo envio dentro do prazo correto para o Linux 6.20.
Esse episódio também mostra algo importante para quem olha o kernel de fora: “grandes” contribuidores não recebem passe livre. O kernel funciona como uma linha de produção com inspeção rígida porque uma regressão escondida num PR enorme pode custar meses de dor para todo mundo depois.
O que esperar no Linux 6.20
O reagendamento para o Linux 6.20 tende a melhorar as chances do Gaudi3 por um motivo simples: dá tempo para fatiar, revisar e testar. Em geral, isso envolve transformar um monólito em uma sequência mais digerível: primeiro as bases comuns, depois a MMU v3, depois ODP, depois as peças específicas do ASIC e, por fim, o acabamento de debug, sysfs e segurança. Para HPC e IA, onde estabilidade e previsibilidade são essenciais, esse é o caminho que reduz risco sem matar inovação.
