Pourquoi l'API du module Linux n'est-elle pas rétrocompatible ?
Pourquoi l'API du module Linux n'est-elle pas rétrocompatible ? Je suis frustré de trouver des pilotes mis à jour après la mise à jour du noyau Linux.
J'ai un adaptateur sans fil qui nécessite un pilote propriétaire, mais le fabricant a abandonné cet appareil il y a environ 7 ans. Comme le code est très ancien et a été écrit pour Linux 2.6.0.0, il ne se compile pas avec les derniers noyaux Linux. J'ai utilisé de nombreuses distributions Linux mais le même problème est partout. Bien qu'il existe un pilote open source distribué avec le noyau Linux, cela ne fonctionne pas. Certaines personnes essaient de modifier l'ancien code propriétaire pour le rendre compatible avec les derniers noyaux Linux, mais lorsqu'un nouveau noyau Linux est publié, il faut des mois pour rendre le code compatible avec celui-ci. Pendant ce temps, une autre nouvelle version est publiée. Pour cette raison, je ne peux pas mettre à niveau vers un nouveau noyau Linux ; parfois je ne peux même pas mettre à jour ma distribution.
Réponses
Greg Kroah-Hartman a écrit sur ce sujet ici :https://www.kernel.org/doc/html/v4.10/process/stable-api-nonsense.html
Outre quelques détails techniques concernant la compilation du code C, il dégage quelques problèmes d'ingénierie logicielle de base qui prennent leur décision.
Le noyau Linux est toujours un travail en cours. Cela se produit pour de nombreuses raisons :
- De nouvelles exigences arrivent. Les gens veulent que leur logiciel en fasse plus, c'est pourquoi la plupart d'entre nous mettons à niveau, nous voulons les fonctionnalités les plus récentes et les plus performantes. Ceux-ci peuvent nécessiter une refonte du logiciel existant.
- Des bogues sont trouvés qui doivent être corrigés, parfois les bogues sont avec la conception elle-même et ne peuvent pas être corrigés sans une refonte importante
- De nouvelles idées et idiomes dans le monde du logiciel se produisent et les gens trouvent des moyens beaucoup plus faciles / élégants / efficaces de faire les choses.
C'est le cas de la plupart des logiciels , et tout logiciel qui n'est pas maintenu mourra d'une mort lente et douloureuse . Ce que vous demandez, c'est pourquoi cet ancien code non maintenu ne fonctionne-t-il pas toujours?
Pourquoi les anciennes interfaces ne sont-elles pas maintenues ?
Pour assurer la rétrocompatibilité, il faudrait que les anciennes interfaces (souvent « cassées » et non sécurisées) soient conservées. Bien sûr, il est théoriquement possible de le faire, sauf que cela entraîne des coûts importants .
Greg Kroah-Hartman écrit
Si Linux devait s'assurer qu'il conservera une interface source stable, une nouvelle interface aurait été créée, et l'ancienne, cassée, aurait dû être maintenue au fil du temps, ce qui entraînerait un travail supplémentaire pour les [développeurs]. Étant donné que tous les [développeurs] Linux font leur travail pendant leur temps libre, demander aux programmeurs de faire un travail supplémentaire sans gain, gratuitement, n'est pas une possibilité.
Même si Linux est open source, il n'y a encore que peu de temps de développement pour le maintenir. La main-d'œuvre peut donc encore être discutée en termes de "coût". Les développeurs doivent choisir comment ils passent leur temps :
- Passez beaucoup de temps à maintenir des interfaces anciennes / cassées / lentes / non sécurisées. Cela peut parfois être du double au triple du temps qu'il a fallu pour écrire l'interface dans la première instance.
- Jetez les anciennes interfaces et attendez-vous à ce que les autres mainteneurs de logiciels [font leur travail et] maintiennent leur propre logiciel.
Dans l'ensemble, les interfaces de binning sont vraiment rentables (pour les développeurs du noyau) . Si vous voulez savoir pourquoi les développeurs ne passent pas des mois et des années de leur vie à vous éviter de payer 10 $ pour un nouvel adaptateur wifi... c'est la raison. N'oubliez pas que c'est un gain de temps et d'argent pour les développeurs du noyau, pas nécessairement pour vous ou pour les fabricants.
Bien que j'aie apporté quelques correctifs (très mineurs) au noyau Linux, je ne me considère pas comme un développeur du noyau. Cependant, voici ce que je sais :
Un pilote écrit pour la version 2.6.0.0 du noyau est antérieur à l'élimination du Big Kernel Lock (BKL) qui s'est produit dans la version 2.6.39 du noyau.
Le BKL a été créé à l'époque où Linux était encore un système d'exploitation à processeur unique (cœur unique, thread unique). Dès que le support SMP a été ajouté, les développeurs ont reconnu que le BKL allait devenir un gros goulot d'étranglement à un moment donné, mais tant qu'il n'y avait que quelques cœurs/threads dans le système au total, c'était quelque peu tolérable. Mais c'est d'abord devenu un vrai problème pour les personnes utilisant Linux dans les superordinateurs, et donc le travail a commencé à remplacer tout ce qui avait besoin du BKL par des mécanismes de verrouillage plus fins, ou chaque fois que possible, par des méthodes sans verrouillage.
Sur les ordinateurs modernes, qui peuvent avoir un nombre de cœurs à deux chiffres sur les ordinateurs de bureau ordinaires et les ordinateurs portables à haute puissance, sans parler des serveurs, une API de module de noyau rétrocompatible 2.6.0 devrait également implémenter BKL.
Si un module hérité dit "Je veux prendre le BKL", le reste du noyau n'a aucune idée de ce que le module prévoit d'en faire, et donc le mécanisme de rétrocompatibilité devrait prendre tous les verrous qui ont remplacé le BKL juste pour couvrir toutes les possibilités. Ce serait un gros coup de performance. Et les nouvelles méthodes sans verrou devraient également vérifier le verrou hérité - qui va à l'encontre de l'intérêt d'être sans verrou en premier lieu. Ainsi, l'existence même du mécanisme de compatibilité descendante dégraderait les performances du système, même si aucun module hérité n'était réellement chargé.
Plus récemment, les correctifs de sécurité Spectre/Meltdown ont apporté de grands changements dans ce qui doit se passer lorsque la frontière noyau/espace utilisateur est franchie. Tous les modules compilés avant l'implémentation des correctifs Spectre/Meltdown peuvent ne pas être fiables avec les noyaux post-Specre/Meltdown.
Il y a à peine deux semaines, je dépannais un ancien serveur qui nécessitait un redémarrage manuel lorsque des mises à jour de sécurité étaient appliquées par automatisation. Cela s'était produit plusieurs fois auparavant et était reproductible. J'ai découvert qu'il avait une très ancienne version du megasrpilote de stockage propriétaire d'avant les correctifs Spectre/Meltdown, qui n'était pas inclus dans les mises à jour automatiques. Après la mise à jour du pilote vers la version actuelle, le problème a disparu. Soit dit en passant, c'était sur un système RHEL 6.10 ordinaire.
J'ai également vu des serveurs planter lors du chargement de pilotes de surveillance matériels propriétaires pré-Spectre/Meltdown avec un noyau post-Spectre/Meltdown. Sur la base de cette expérience, je suis pleinement convaincu que les correctifs Spectre/Meltdown doivent être traités comme un événement décisif : le noyau et les modules doivent être soit tous des correctifs antérieurs, soit des versions postérieures aux correctifs ; le mélange et l'appariement n'entraîneront que du chagrin et des appels de réveil à minuit pour l'administrateur système de garde.
Et puisque Spectre était un problème au niveau de la conception du processeur , c'est "un cadeau qui continue de donner": certaines personnes trouveront de nouvelles façons d'exploiter les faiblesses, puis les développeurs du noyau devront trouver des moyens de bloquer les exploits.
Ce ne sont là que deux des gros problèmes qu'une API de module de noyau héritée compatible 2.6.0.0 devrait résoudre. Je suis sûr qu'il y en a beaucoup d'autres.
Et puis il y a le côté plus philosophique. Pensez-y : qu'est-ce qui rend Linux possible ?
Il s'agit en grande partie de spécifications matérielles ouvertes . Si les spécifications matérielles sont ouvertes, n'importe qui peut participer. Comme le code source du système d'exploitation est ouvert, n'importe qui peut y contribuer, pour le bénéfice de tous. Et vous ne pouvez pas conserver les spécifications de programmation matérielle comme secret commercial si votre code de pilote est open source.
Les développeurs du noyau Linux ont tendance à croire au modèle open source. C'est pourquoi ils ont fait leurs choix de conception et de développement afin que la manière préférée pour le fabricant de matériel de participer soit d'ouvrir le pilote, de le fusionner dans la distribution principale des sources du noyau, puis (et alors seulement ) vous profiter de l'ensemble de la communauté des développeurs du noyau pour sa maintenance.
Cela incite les concepteurs et les fabricants de matériel à rendre cela possible. Si vous avez quelque chose que vous souhaitez garder secret, faites l'effort de l'encapsuler dans un ASIC, ou peut-être dans un firmware signé si vous le devez. (Si vous faites ce dernier, veuillez accorder aux autres la permission de redistribuer le progiciel.)
Mais comme le noyau est open source, les développeurs du noyau ne peuvent pas exactement empêcher les autres de gérer séparément les pilotes propriétaires. Mais ils n'ont aucune incitation à s'en soucier non plus.
En fait, les tracas supplémentaires causés par les pilotes binaires propriétaires dans le débogage du noyau incitent les développeurs du noyau à ne pas se soucier du développement de pilotes propriétaires : "Ils rendent mon travail plus difficile, pourquoi devrais-je faire quelque chose en particulier pour rendre le leur plus facile ?"
Ainsi, les développeurs du noyau font généralement ce qui est le plus avantageux pour eux en tant que groupe/communauté. Si cela inclut un changement d'API de module, qu'il en soit ainsi. Les pilotes tiers n'entrent même pas dans l'équation.