Linus Torvalds rejeita duramente as atualizações do RISC-V para o Linux 6.17, chama código de “lixo”

Escrito por
Emanuel Negromonte
Emanuel Negromonte é Jornalista, Mestre em Tecnologia da Informação e atualmente cursa a segunda graduação em Engenharia de Software. Com 14 anos de experiência escrevendo sobre...

Rejeição dura expõe padrões do kernel: atraso e “código lixo” no RISC-V

“Não. Isso é lixo e chegou tarde demais.” A sentença abriu mais um e-mail contundente de Linus Torvalds na LKML. O alvo: o pull request de RISC-V para o Linux 6.17, rejeitado em público por dois motivos centrais — foi enviado tarde e trouxe código lixo para arquivos genéricos do kernel. Em outras palavras, quebrou regras fundamentais de processo e de engenharia que sustentam o projeto.

Tarde demais e de baixa qualidade: os motivos da rejeição

Torvalds deixou claro que havia pedido pull requests antecipados porque estaria viajando e, portanto, tolerância zero para atrasos — especialmente quando o conteúdo não está impecável.

“No. This is garbage and it came in too late.”

“I asked for early pull requests because I’m traveling, and if you can’t follow that rule, at least make the pull requests good.”

Além do timing, o problema técnico: o pacote “adiciona vários lixos” em headers genéricos — regiões compartilhadas por todas as arquiteturas — com mudanças que não são específicas de RISC-V. Isso fere uma regra de organização do kernel: código específico de arquitetura não deve “poluir” áreas comuns, pois degrada a coesão, dificulta revisão e aumenta o risco de regressões em outras plataformas.

“This adds various garbage that isn’t RISC-V specific to generic header files.”

Torvalds também rejeitou a estratégia de “embarcar um pull grande no dia anterior ao fim da janela de merge” esperando que ele estivesse ocupado demais para analisar — e avisou que isso “não é uma estratégia vencedora”.

Uma lição pública sobre qualidade de código

O exemplo que sintetiza o veredito de Torvalds é a função helper make_u32_from_two_u16(). À primeira vista, ela parece “abstrair” a composição de dois u16 em um u32. Na prática, afirma Linus, piora a legibilidade, induz ambiguidades de ordem de palavras (alto/baixo), e é inferior à forma explícita:

  • claro e direto: (a << 16) + b
  • opaco e ambíguo: make_u32_from_two_u16(a, b)

“Like this crazy and pointless make_u32_from_two_u16() ‘helper’.”

“That thing makes the world actively a worse place to live.”

O ponto de engenharia por trás da bronca: no kernel, clareza explícita vence “azulejos” de abstração que escondem semântica. O helper não deixa óbvio qual é a word alta e qual é a baixa; já a expressão com shift revela a intenção, até quando é preciso “enfeiar” um pouco o código com casts para evitar propagação de bits indesejados. Em termos de manutenção, um leitor experiente entende (a << 16) + b em uma passada; a versão helper exige caça à definição, contexto e contrato — custo cognitivo que não agrega.

Torvalds ainda reforçou o limite organizacional: nada de “lixo” fora da árvore de RISC-V, muito menos em headers genéricos. E foi taxativo ao impor consequências:

“You’re on notice: no more late pull requests, and no more garbage outside the RISC-V tree.”

Por fim, o recado operacional: o mantenedor de RISC-V “poderá tentar de novo no 6.18” — no começo da janela e sem o lixo.

Compartilhe este artigo