Um dos recursos interessantes do Thunderbolt e agora do USB4 que aparentemente não é muito usado é a rede entre sistemas. O kernel Linux da última meia década já ofereceu um driver de rede Thunderbolt para rede entre hosts com cabos Thunderbolt. A mais recente melhoria em relação a isto agora suporta o modo de controle de fluxo de ponta a ponta do USB4.
O driver de rede Linux Thunderbolt/USB4 começou visando o protocolo Apple ThunderboltIP, que evoluiu para USB4NET. Os engenheiros da Intel têm mantido esse driver de rede como em grande parte da pilha de software Thunderbolt Linux.
O driver de rede Thunderbolt/USB4 para Linux agora está habilitando suporte para controle de fluxo de ponta a ponta, que faz parte da especificação e é suportado pelos controladores da Intel. O modo de controle de fluxo de ponta a ponta evita o descarte de pacotes quando não há buffers de receptor de hardware suficientes.
Rede Linux 6.1 Thunderbolt vai suportar controle de fluxo de ponta a ponta USB4
Mais detalhes sobre o modo de controle de fluxo de ponta a ponta podem ser encontrados nesta apresentação USB IF.
Essa melhoria de qualidade de serviço para o driver de rede Linux USB4/Thunderbolt foi enfileirada no net-next antes da janela de mesclagem do Linux 6.1.
FWUPD explora melhorias para atualização de firmware mais fácil e robusta no Linux
Atualmente, quando se trata de enviar suporte a dispositivos novos/atualizados para atualização de firmware no Linux com FWUPD/LVFS, é necessário fazer/ajustar um plug-in Fwupd para realizar a cópia/atualização de firmware real do dispositivo e, em seguida, adicionar o VID do dispositivo /PID para uma tabela de peculiaridades para que o Fwupd saiba com o que corresponder um determinado dispositivo para o plug-in de firmware usar.
Mesmo em novos dispositivos em que nenhuma alteração de plug-in é necessária, novas entradas de dispositivo ainda são necessárias na tabela de peculiaridades e torna-se um desafio quando as distribuições Linux não migram rapidamente para novas versões do FWUPD. Avançando, uma solução melhor está sendo explorada.
Devido às semanas ou meses que as distribuições Linux levam para migrar para novas versões do FWUPD, não é fácil obter uma nova tabela de peculiaridades para o FWUPD, mesmo quando nenhuma alteração de plug-in é necessária.
Esse tempo necessário antes que novos lançamentos do FWUPD sejam adotados/difundidos é uma das barreiras significativas para que novos dispositivos usufruam de suporte de atualização de firmware no Linux. O desenvolvedor líder do Fwupd e do Linux Vendor Firmware Service (LVFS), Richard Hughes da Red Hat, vem explorando uma alternativa nessa área.
Em vez de depender de uma tabela de peculiaridades VID/PID para combinar dispositivos com plug-ins FWUPD, ele está analisando a possibilidade de o firmware do dispositivo fornecer as informações necessárias para que não exija nenhuma adição de tabela de peculiaridades.
Para que o firmware seja capaz de comunicar o plug-in FWUPD ao sistema host, ele está analisando a possibilidade de usar a especificação Microsoft OS Descriptors. A especificação Microsoft OS Descriptors permite que os IHVs armazenem no firmware informações que podem ser usadas para ajudar a instalar/configurar o dispositivo no Windows.
Richard está pensando em possivelmente fazer uso da Especificação de Descritores do Microsoft OS 2.0 com conjuntos de descritores para que o firmware possa comunicar ao sistema qual plug-in FWUPD ou detalhes são necessários para suporte de atualização de firmware. Para isso, visite os Documentos da Microsoft.
Obviamente, isso exige que os fornecedores de hardware realmente optem por disponibilizar essas informações por meio de seu firmware. Richard espera que o LVFS/FWUPD tenha tração suficiente agora, especialmente devido ao uso do Google ChromeOS, que os IHVs estarão mais dispostos a fazer as alterações de firmware agora para beneficiar esse caso de uso.
Por sua vez, para os fornecedores, isso significaria uma implementação mais fácil do suporte à atualização de firmware no Linux e Chrome OS quando os plug-ins existentes forem adequados e evitarão o longo tempo de resposta ao lançar novas atualizações da tabela de peculiaridades.
Veja o blog de Richard sobre esta nova proposta e ele indicou que planeja começar a prototipar o novo código na próxima semana se tudo correr bem.