- Dobro ou nada: A especificação PCIe 7.0 promete 128 GT/s, dobrando a velocidade da geração anterior e exigindo novas estratégias de codificação como o modo Flit obrigatório.
- O erro da continuidade: A proposta inicial de suporte no kernel falhou ao assumir que a Gen 7 seguiria o mesmo padrão de registros das gerações 3 a 6.
- Revisão salvadora: A intervenção técnica de Ilpo Järvinen evitou a inclusão de código que buscava velocidades em lugares errados, destacando a importância da revisão por pares.
- Nova arquitetura: Para suportar velocidades extremas, o hardware mudou a forma de reportar capacidades, exigindo que o Linux aprenda a ler novas estruturas estendidas em vez de bits legados.
- Codando no escuro: O caso exemplifica a dificuldade de desenvolver drivers para tecnologias que ainda não existem fisicamente no mercado.
A próxima fronteira da conectividade de alta velocidade chegou à lista de discussão do kernel Linux. Em 17 de fevereiro de 2026, o desenvolvedor Ionut Nechita submeteu uma série de patches RFC (Request for Comments) propondo o suporte inicial para o PCI Express Gen 7, que promete dobrar a taxa de transferência de dados para impressionantes 128 GT/s.
No entanto, o que parecia ser uma atualização trivial de definições revelou-se um conflito interessante entre a implementação de software e a realidade da especificação de hardware, mostrando que nem sempre o futuro segue os padrões do passado.
O salto para 128 GT/s
A especificação PCIe 7.0 é um monstro de performance. Utilizando sinalização PAM4 e tornando o modo Flit (Flow Control Unit) obrigatório, ela elimina o overhead de codificação (operando em 1:1) para entregar até 512 GB/s de largura de banda bidirecional em um slot x16.
Para o kernel Linux, suportar isso significa ser capaz de detectar, negociar e relatar essas velocidades corretamente. A proposta inicial de Nechita tentou seguir a lógica das gerações anteriores (Gen 3, 4, 5 e 6), onde cada nova velocidade era apenas um novo bit em um registro de capacidades existente.
Onde a lógica quebrou
A série de patches tentou implementar o suporte estendendo as definições atuais. O desenvolvedor expandiu variáveis de 8 bits para 16 bits (u8 para u16) e definiu o próximo bit disponível nos registros de capacidade de link (LNKCAP) como o indicador para 128 GT/s.
Foi aí que a revisão técnica de Ilpo Järvinen freou a empolgação.
Ao analisar o código, Järvinen questionou as definições de registro, perguntando se elas haviam sido “inventadas”, pois não correspondiam à especificação oficial da PCI-SIG. A realidade técnica do PCIe 7.0 é que ele rompe com o método legado de descoberta de velocidade.
A nova estrutura de capacidade
Diferente das atualizações anteriores, onde bastava checar o “próximo bit”, a especificação para velocidades de 128 GT/s ou superiores exige que o software leia uma nova estrutura de capacidade estendida (“128 GT/s Capability”).
Tentar ler a velocidade Gen 7 nos registros antigos (LNKCAP2) retornará dados incorretos ou inválidos. O kernel precisa aprender a procurar essa nova estrutura no espaço de configuração do dispositivo, algo que os patches propostos não faziam.
Desenvolvimento “às cegas”
Este episódio ilustra um desafio comum no desenvolvimento de kernels: escrever drivers para hardware que ainda não existe fisicamente. Os patches foram marcados como “testados apenas via compilação”, pois não há dispositivos Gen 7 no mercado para validar a implementação.
Embora a intenção de preparar o Linux antecipadamente seja válida, a revisão rigorosa da comunidade evitou que um código baseado em suposições incorretas fosse integrado, o que poderia causar dores de cabeça para os engenheiros de hardware no futuro.
O suporte ao PCIe 7.0 virá, mas exigirá uma reescrita da lógica de detecção de velocidade do kernel, abandonando os atalhos que funcionaram até a Gen 6.
