E a saga dos drivers para o kernel Linux não irá acabar tão cedo…

Ao menos, não do jeito que a gente espera! Há tempos, o kernel convive com o “problema” do inchaço de sua base de código, causado principalmente pela adição constante de drivers, para suportar uma infinidade de hardwares e periféricos. Em parte, isto já é algo esperado. Estamos falando de um sistema que foi concebido para rodar em praticamente todo o tipo de plataforma de hardware: relógios digitais, sensores IoT, switches & roteadores, consoles portáteis, mainframes & supercomputadores e até mesmo em robôs e máquinas autônomas…

Em virtude desta incrível variedade de plataformas e a necessidade de prover todo o suporte necessário para elas, o kernel Linux é composto majoritariamente de drivers, além das bibliotecas, APIs e outros componentes essenciais para o seu funcionamento. Isto, sem falar também no suporte a praticamente todos os set de instruções ISA dos processadores, como é o caso do x86, ARM, RISC-V, PowerPC e MIPS, entre outros. Isto gerou uma base de código gigantesca, a qual tende a crescer ainda mais conforme novos componentes de hardwares vão sendo lançados.

O caso mais crítico são os drivers para as GPUs. Por serem componentes dotados de uma arquitetura complexa e exigirem otimizações para que possamos tirar o máximo de proveito do hardware, eles geralmente são constituídos por milhões de linhas de código, como é o caso da AMD que é “recordista” neste aspecto. E a tendência é ver estes números aumentarem ainda mais, em vista da ascensão do SteamOS nos consoles portáteis e a própria Nvidia, ao abandonar os módulos proprietários das suas GPUs, em prol de módulos baseados em código aberto.

À princípio, a solução parece ser óbvia: remover o suporte para hardwares de legado e/ou que não estão sendo utilizados. Mas na prática, não é bem assim: por ser um sistema universal, que tem como princípio promover o suporte para todo o tipo de hardware existente, muitos deles ainda continuam sendo utilizados, ainda que tenham sido lançados há decadas e que sejam utilizados por uma parcela ínfima de usuários. Não raro, há casos em que CPUs e outros componentes antigos ainda continuam sendo utilizados atualmente, em plataformas que necessitam de um pequeno poder de processamento para executar tarefas triviais.

Felizmente, Linus Torvalds e seus contribuidores têm realizado uma série de ações, para reduzir o inchaço da base de código do kernel Linux. Embora ele tenha promovido de forma sistemática a eliminação do suporte para hardwares que já não são mais utilizados, na prática ele estabeleceu e aplicou rigorosamente uma filosofia de manutenção de drivers e seus subsistemas, a qual prioriza os usuários e a evolução saudável do kernel. Isto acaba tendo o “efeito colateral” de eliminar códigos de drivers, que não se enquadram nestes requisitos.

Em destaque, está remoção agressiva de drivers obsoletos e órfãos, colocando-os na árvore staging para que sejam eliminados posteriormente, caso não apareçam interessados em mantê-los. Torvalds também estabeleceu a rígida política de “não quebrar o espaço do usuário”, incentivando a melhorar (ou remover) os drivers que causam problemas ao sistema, devido a questão da compatibilidade com a ABI (Interface Binária de Aplicação). Por fim, ele também promove um controle de qualidade mais exigente, para a aceitação de novos drivers na árvore principal do kernel Linux (se eles não atenderem aos requisitos, não serão permitidos).

Infelizmente, o inchaço do kernel é apenas um sintoma inicial de um problema bem maior, que já vem dando as caras há algum tempo (e não tem sido observado com a devida atenção): a obsoleta arquitetura de código adotada e as dificuldades técnicas para mantê-la atualizada. O kernel Linux é monolítico por natureza (embora utilize módulos para carregar/descarregar os drivers), o que obriga a manter os drivers na árvore oficial do kernel. A partir do momento em que as suas APIs internas e/ou os subsistemas tenham alguma mudança estrutural, faz-se necessário atualizar toda a base de códigos dos drivers que dependem deles.

Mas este, será o tópico central de uma próxima coluna… &;-D

Leave a Comment