Imaginez qu'il existe une entreprise A qui publie un nouvel adaptateur graphique. Qui gère le processus qui aboutit à ce que cette nouvelle carte graphique soit prise en charge par le noyau Linux à l'avenir? Comment cela se passe-t-il? Je suis curieux de savoir comment le support du noyau pour tout nouveau matériel est géré; sur Windows, les entreprises développent leurs propres pilotes, mais comment Linux obtient-il un support matériel spécifique?
Réponses:
La prise en charge des pilotes fonctionne de la même manière que pour tous les logiciels open source: quelqu'un décide de se gratter.
Parfois, le pilote est fourni par la société fournissant le matériel, tout comme sous Windows. Intel le fait pour ses puces réseau, 3ware le fait pour ses contrôleurs RAID, etc. Ces sociétés ont décidé qu'il est dans leur intérêt de fournir le pilote: leur "démangeaison" est de vendre des produits aux utilisateurs Linux, et cela signifie qu'il y a un chauffeur.
Dans le meilleur des cas, la société travaille dur pour obtenir son pilote dans la base source appropriée livrée avec les distributions Linux. Pour la plupart des pilotes, cela signifie le noyau Linux. Pour les pilotes graphiques, cela signifie X.org . Il existe également CUPS pour les pilotes d'imprimante, NUT pour les pilotes UPS, SANE pour les pilotes de scanner, etc. Le plus gros inconvénient est qu'il est plus difficile pour l'entreprise de se coordonner avec le projet open source pour obtenir son pilote, pour les mêmes raisons fondamentales, il est difficile pour deux groupes distincts de coordonner quoi que ce soit.
Ensuite, il y a les entreprises qui choisissent d'offrir directement leur code source de pilote. Vous devez généralement télécharger le code source du pilote à partir de leur site Web, le créer sur votre système et l'installer à la main. Ces entreprises sont généralement des fabricants plus petits ou spécialisés sans suffisamment d'employés pour épargner l'effort de coordination avec le projet open source approprié pour obtenir leur pilote dans la base source de ce projet.
Quelques rares entreprises fournissent des pilotes binaires uniquement au lieu du code source. Un exemple est les pilotes 3D plus avancés de sociétés comme NVIDIA. Généralement, cela s'explique par le fait que l'entreprise ne souhaite pas divulguer d'informations sur lesquelles elle se sent propriétaire. Ces pilotes ne fonctionnent souvent pas avec autant de distributions Linux que dans les cas précédents, car la société fournissant le matériel ne prend pas la peine de reconstruire son pilote pour suivre les modifications d'API et d'ABI. Il est possible pour l'utilisateur final ou le fournisseur de distribution Linux de modifier un pilote fourni en tant que code source pour suivre ces modifications, donc dans les deux cas précédents, le pilote peut généralement être configuré pour fonctionner avec plus de systèmes qu'un pilote binaire.
Lorsque l'entreprise ne fournit pas de pilotes Linux, quelqu'un dans la communauté décide simplement de le faire. Il existe de grandes classes de matériel où cela est courant, comme avec les onduleurs et les imprimantes. Il faut un utilisateur rare qui a) possède le matériel; b) a le temps; c) possède la compétence; et d) a tendance à consacrer du temps au développement du conducteur. Pour le matériel populaire, ce n'est généralement pas un problème car avec des millions d'utilisateurs Linux, ces quelques personnes existent. Vous rencontrez des problèmes avec du matériel peu courant.
Pour comprendre cela en détail, récemment Raspberry Pi 3 est sorti et a ajouté une puce Bluetooth. Maintenant, c'est une puce Broadcom BLE et le noyau Raspberry Pi n'est pas pris en charge et la bluezbibliothèque pour Linux ne fonctionne donc pas. Maintenant, idéalement, on devrait avoir un patch de firmware pour cette puce BLE et il faudra recompiler le noyau pour le rendre disponible à l'utilisateur. Est-ce correct?