Imagine que há uma empresa A que lança um novo adaptador gráfico. Quem gerencia o processo que resulta nesse novo adaptador gráfico sendo suportado pelo kernel Linux no futuro? Como isso acontece? Estou curioso para saber como o suporte do kernel para qualquer novo hardware é tratado; no Windows, as empresas desenvolvem drivers por conta própria, mas como o Linux obtém suporte de hardware específico?
Respostas:
O suporte ao driver funciona da mesma maneira que com todo o código aberto: alguém decide coçar a própria coceira.
Às vezes, o driver é fornecido pela empresa que fornece o hardware, assim como no Windows. A Intel faz isso pelos chips de rede, a 3ware faz pelos controladores RAID etc. Essas empresas decidiram que é do seu interesse fornecer o driver: a "coceira" é vender produtos para usuários do Linux, e isso significa garantir que existe um motorista.
Na melhor das hipóteses, a empresa trabalha duro para colocar o driver na base de origem apropriada que acompanha as distribuições do Linux. Para a maioria dos drivers, isso significa o kernel do Linux. Para drivers gráficos, significa X.org . Também existem CUPS para drivers de impressora, NUT para drivers de UPS, SANE para drivers de scanner etc. O benefício óbvio de fazer isso é que as distribuições do Linux feitas após a aceitação do driver terão suporte para o hardware pronto para uso. A maior desvantagem é que é mais trabalho para a empresa se coordenar com o projeto de código aberto para obter seu direcionamento, pelas mesmas razões básicas, é difícil para dois grupos separados coordenar qualquer coisa.
Depois, existem empresas que optam por oferecer seu código-fonte diretamente, apenas. Você normalmente precisa baixar o código-fonte do driver no site deles, compilá-lo no sistema e instalá-lo manualmente. Essas empresas geralmente são fabricantes menores ou especializados, sem funcionários suficientes para poupar o esforço de coordenar o projeto de código aberto apropriado para colocar seu driver na base de origem do projeto.
Algumas empresas raras fornecem drivers apenas 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 deseja divulgar informações sobre as quais se sente proprietária. Esses drivers geralmente não funcionam com tantas distribuições Linux como nos casos anteriores, porque a empresa que fornece o hardware não se preocupa em reconstruir seu driver para rastrear alterações de API e ABI. É possível que o usuário final ou o provedor de distribuição do Linux ajuste um driver fornecido como código-fonte para rastrear essas alterações; portanto, nos dois casos anteriores, o driver geralmente pode ser feito para trabalhar com mais sistemas do que um driver binário.
Quando a empresa não fornece drivers para Linux, alguém da comunidade simplesmente decide fazê-lo. Existem algumas classes grandes de hardware onde isso é comum, como no-breaks e impressoras. É necessário um usuário raro que a) possua o hardware; b) tem tempo; c) tem a habilidade; e d) tem a tendência de gastar o tempo para desenvolver o motorista. Para hardware popular, isso geralmente não é um problema, porque com milhões de usuários de Linux, essas poucas pessoas existem. Você enfrenta problemas com hardware incomum.
Para entender isso em detalhes, recentemente o Raspberry Pi 3 foi lançado e adicionou um chip bluetooth. Agora, esse é um chip Broadcom BLE e o kernel do Raspberry Pi não tem suporte para ele, portanto a bluezbiblioteca para 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 disponibilizá-lo ao usuário. Isso esta certo?