Como o novo suporte de hardware é adicionado ao kernel do Linux?

18

Imagine que existe uma empresa A que libera um novo adaptador gráfico. Quem gerencia o processo que resulta no novo adaptador gráfico suportado pelo kernel do Linux no futuro? Como isso acontece? Estou curioso sobre como o suporte ao kernel para qualquer novo hardware é tratado; em empresas Windows desenvolvem drivers por conta própria, mas como o Linux obtém suporte de hardware específico?

    
por NES 24.12.2010 / 01:11

2 respostas

25

O suporte ao driver funciona da mesma maneira que todo o código aberto: alguém decide coçar sua própria coceira.

Às vezes, o driver é fornecido pela empresa que fornece o hardware, assim como no Windows. A Intel faz isso por seus chips de rede, a 3ware faz isso por seus controladores RAID, etc. Essas empresas decidiram que é de seu interesse fornecer o driver: sua "coceira" é vender produtos para usuários Linux, e isso significa garantir que existe um driver.

No melhor dos casos, a empresa trabalha duro para colocar seu driver na base de origem apropriada que vem com distribuições Linux. Para a maioria dos drivers, isso significa o kernel do Linux. Para drivers gráficos, isso significa X.org . Há também CUPS para drivers de impressora, NUT para o UPS drivers, SANE para drivers de scanner, etc. O benefício óbvio de fazer isso é que as distribuições do Linux feitas após o driver ser aceito terão suporte para o hardware fora da caixa. A maior desvantagem é que é mais trabalho para a empresa coordenar com o projeto de código aberto para obter o driver, pelas mesmas razões básicas, é difícil para dois grupos separados coordenar qualquer coisa.

Depois, há aquelas empresas que optam por oferecer seu código-fonte de driver diretamente, apenas. Você normalmente precisa baixar o código-fonte do driver do site, compilá-lo no sistema e instalá-lo manualmente. Essas empresas geralmente são fabricantes menores ou de especialidade, sem empregados suficientes, que podem poupar esforços para coordenar com o projeto de código aberto adequado para colocar o motorista na base de origem do projeto.

Algumas empresas raras fornecem drivers somente binários em vez de código-fonte. Um exemplo são os drivers 3D mais avançados de empresas como a NVIDIA. Normalmente, a razão para isso é que a empresa não quer dar informações sobre as quais se sentem proprietários. Esses drivers geralmente não funcionam com tantas distribuições do Linux quanto nos casos anteriores, porque a empresa que fornece o hardware não se preocupa em reconstruir o driver para rastrear alterações na API e na ABI. É possível que o usuário final ou o provedor de distro do Linux ajuste um driver fornecido como código-fonte para rastrear essas mudanças, de modo que nos dois casos anteriores, o driver geralmente pode funcionar com mais sistemas do que um driver binário.

Quando a empresa não fornece drivers para Linux, alguém na comunidade simplesmente decide fazê-lo. Existem algumas grandes classes de hardware, onde isso é comum, como com UPS e impressoras. É preciso um usuário raro que a) tenha o hardware; b) tem o tempo; c) tem a habilidade; e d) tem a inclinação para gastar o tempo para desenvolver o driver. Para hardware popular, isso geralmente não é um problema porque, com milhões de usuários de Linux, essas poucas pessoas existem. Você tem problemas com hardware incomum.

    
por 24.12.2010 / 02:41
0

Para entender isso em detalhes, recentemente o Raspberry Pi 3 foi lançado e adicionado o chip bluetooth. Agora, esse é um chip Broadcom BLE e o kernel do Raspberry Pi não tem suporte para isso e, portanto, a biblioteca bluez do Linux não funciona. Agora, idealmente, deve-se ter um patch de firmware para esse chip BLE e será necessário compilar o kernel novamente para torná-lo disponível ao usuário. Isso esta certo?

    
por 01.09.2016 / 22:09