Linux 5.15-rc1 traz novo driver NTFS, servidor SMB3 no kernel, alterações de AMD e Intel DG2

Como esperado, na noite deste domingo saiu a esperada primeira versão candidata a lançamento do kernel Linux 5.15-rc1. Assim, fecha-se a janela de fusão de duas semanas que obteve muitas mudanças no kernel. O novo Linux 5.15-rc1 traz novo driver NTFS, servidor SMB3 no kernel, alterações de AMD e Intel DG2.

Amanhã terei publicado nossa ampla visão geral dos recursos das alterações do Linux 5.15, mas alguns dos destaques incluem Paragon NTFS3 como o novo driver do sistema de arquivos NTFS, KSMBD como um servidor de arquivos SMB3 no kernel, limpeza de cache L1d opcional no contexto comutação, trabalho contínuo de apresentação do Apple M1, muitas melhorias de AMD e trabalho de apresentação de gráficos discretos Intel DG2/Alchemist e XeHP, entre muitos outros novos recursos de hardware.

Linux 5.15-rc1 traz novo driver NTFS, servidor SMB3 no kernel, alterações de AMD e Intel DG2

Linus Torvalds escreveu sobre o Linux 5.15-rc1 no anúncio:

Portanto, o 5.15 não parece ser um lançamento particularmente grande, pelo menos em número de commits. Com apenas pouco mais de 10k commits de não mesclagem, este é de fato o menor rc1 que tivemos na série 5.x. Normalmente, estamos pairando na faixa de confirmação de 12-14k. Dito isso, contar commits não é necessariamente a melhor medida, e isso pode ser particularmente verdadeiro desta vez. Temos alguns novos subsistemas, com destaque para NTFSv3 e ksmbd. E, como resultado, quando você olha as estatísticas em uma base de “linhas alteradas”, 5.15-rc1 acaba parecendo muito mais intermediário. Ainda não se parece com uma janela de mesclagem _big_ particularmente, mas também não é remotamente a menor.

Fique atento para a visão geral completa dos recursos do Linux 5.15 e nossos benchmarks do kernel do Linux 5.15. O Linux 5.15 estável deve ser lançado em novembro.

Desenvolvedores Linux falam novamente sobre um subsistema acelerador

Há anos se fala em um subsistema acelerador para o kernel Linux, considerando que, por enquanto, a maioria dos drivers de acelerador de treinamento/inferência de IA acabam alojados na área “char/misc” do kernel. Essa discussão do subsistema do acelerador foi reiniciada com conversas sobre ter tal subsistema ou mover esses drivers dentro do espaço do subsistema GPU/DRM.

Resultante da recente controvérsia em torno das mudanças no código do driver do Habana Labs AI (embora agora pelo menos parcialmente abordado com a publicação de um compilador de código aberto e biblioteca de espaço do usuário) e como algumas mudanças foram contornadas passando por “char/misc” e enfrentando menos escrutínio do que se as mesmas mudanças fossem tentadas através da árvore de GPU/DRM, a discussão está acontecendo mais uma vez sobre onde esses drivers de aceleração deveriam viver o kernel.

Os drivers do Direct Rendering Manager estão interessados ??em mover os drivers do acelerador dentro dos drivers /gpu, considerando como eles tendem a ser semelhantes com drivers de GPU sem tela e compartilham muitas interfaces e têm objetivos comuns. Viver dentro dos hipotéticos drivers /accel também foi trazido novamente com os mantenedores de DRM ainda interessados ??em supervisionar aquela nova área do kernel.

Greg KH, que supervisiona char/misc, dá as boas-vindas a quaisquer novos revisores e ajuda a gerenciar o código, embora tenha questionado a proposta de alojamento de drivers/gpu e mais firmemente descobrindo alguns dos novos requisitos de driver de acelerador para upstreaming.

Nada foi decidido com firmeza ainda sobre um subsistema de acelerador ou se os mantenedores da GPU/DRM irão supervisionar esses drivers de acelerador no futuro. Os interessados ??na discussão mais recente podem ver este tópico do kernel.

Via Phoronix

Share This Article
Follow:
Jornalista com pós graduações em Economia, Jornalismo Digital e Radiodifusão. Nas horas não muito vagas, professor, fotógrafo, apaixonado por rádio e natureza.
Sair da versão mobile