Toda vez que o Kernel Linux atinge um novo marco de tamanho, uma onda de preocupação superficial toma conta de fóruns e redes sociais. Com o lançamento do Linux 7.3-rc1 ultrapassando as 40,9 milhões de linhas de código, o “culpado” da vez é fácil de identificar. O diretório de drivers gráficos da AMD (AMDGPU e AMDKFD) agora responde por 16% de todo o sistema operacional, somando mais de 6,5 milhões de linhas.
Para quem olha apenas para os números gerados por ferramentas de contagem de código, o cenário parece um pesadelo de otimização. No entanto, interpretar esse volume de texto como “inchaço” ou desleixo por parte da AMD é um erro de leitura técnica. Na verdade, esse gigantismo é o preço que pagamos por uma das melhores estratégias de suporte open source do mercado atual.
O fantasma do “código inchado” e a estratégia da AMD
O próprio Linus Torvalds costuma brincar com o tamanho dos envios da equipe gráfica da AMD durante a fase de release candidates. No Linux 7.3, o salto se deu principalmente pela inclusão do bloco IP DCN 6.0 (Display Core Next). Mas o que exatamente compõe esse código?
A imensa maioria dessas linhas não contém lógicas complexas, laços de repetição infinitos ou rotinas pesadas de processamento. Trata-se de arquivos de cabeçalho em C, repletos de definições de macros. A abordagem da AMD para garantir que suas placas de vídeo funcionem perfeitamente no Linux é mapear fisicamente cada registrador de hardware e despejar isso diretamente no código-fonte aberto.
Essa estratégia difere drasticamente do uso de grandes “bolhas” de código fechado (blobs proprietários) que apenas conversam com o kernel. Ao abrir o dicionário completo de como sua arquitetura funciona, a AMD empodera a comunidade, os desenvolvedores do driver Mesa e os engenheiros da Valve a extraírem o máximo desempenho das GPUs Radeon. O código-fonte fica gigante, mas a transparência é absoluta.
Fonte legível versus binário executável
O maior mito que surge ao observar o tamanho do Kernel Linux é a correlação direta entre linhas de código e consumo de recursos. Um arquivo de cabeçalho com centenas de milhares de linhas mapeando uma futura placa de vídeo com arquitetura RDNA não vai consumir sua memória RAM se você estiver usando um notebook antigo com gráficos integrados da Intel.
O compilador é inteligente o suficiente para transformar essa montanha de texto em módulos binários extremamente enxutos. Durante a inicialização do sistema, o Kernel Linux carrega na memória estritamente o que o seu hardware exige. Aquelas 6,5 milhões de linhas da AMD servem como uma vasta biblioteca de referência para o compilador; elas não são um programa monolítico de 6 milhões de linhas rodando em segundo plano no seu computador.
Um sintoma de sucesso
Se o Kernel Linux está crescendo de forma acelerada por causa de drivers gráficos, isso é um motivo para comemorar, não para lamentar. Significa que as fabricantes estão levando o ecossistema a sério, enviando código de habilitação meses ou anos antes do hardware chegar às prateleiras.
A presença maciça da AMD no núcleo do sistema é o que garante que um usuário possa comprar um lançamento, espetar na placa-mãe, instalar uma distribuição Linux moderna e começar a jogar ou trabalhar imediatamente, sem precisar caçar drivers obscuros na internet. Se isso custa alguns megabytes a mais no download do código-fonte, é um preço que a comunidade técnica deveria pagar com um sorriso no rosto.
