J'ai commencé à réfléchir à ce problème dans le contexte de l'étiquette sur la liste de diffusion du noyau Linux. En tant que projet de logiciel libre le plus connu et sans doute le plus réussi et le plus important au monde, le noyau Linux reçoit beaucoup de presse. Et le fondateur et leader du projet, Linus Torvalds, n'a clairement pas besoin d'être présenté ici.
Linus attire parfois la controverse avec ses flammes sur le LKML. Ces flammes sont souvent, de son propre aveu, liées à la rupture de l'espace utilisateur. Ce qui m'amène à ma question.
Puis-je avoir une perspective historique sur les raisons pour lesquelles rompre l'espace utilisateur est une si mauvaise chose ? Si je comprends bien, briser l'espace utilisateur nécessiterait des correctifs au niveau de l'application, mais est-ce une si mauvaise chose, si cela améliore le code du noyau ?
Si je comprends bien, la politique déclarée de Linus est que ne pas casser l'espace utilisateur l'emporte sur tout le reste, y compris la qualité du code. Pourquoi est-ce si important, et quels sont les avantages et les inconvénients d'une telle politique ?
(Il y a clairement des inconvénients à une telle politique, appliquée de manière cohérente, puisque Linus a parfois des "désaccords" avec ses principaux lieutenants du LKML sur exactement ce sujet. Pour autant que je sache, il obtient toujours ce qu'il veut.)
Réponse acceptée :
La raison n'est pas historique mais pratique. Il existe de nombreux programmes qui s'exécutent au-dessus du noyau Linux; si une interface du noyau casse ces programmes, tout le monde devra mettre à jour ces programmes.
Or, il est vrai que la plupart des programmes ne dépendent en fait pas directement des interfaces du noyau (les appels système), mais uniquement des interfaces de la bibliothèque standard C (C wrappers autour des appels système). Oh, mais quelle bibliothèque standard ? Glib ? uClibC ? Dietlibc ? Bionique? Musul ? etc.
Mais il existe également de nombreux programmes qui implémentent des services spécifiques au système d'exploitation et dépendent d'interfaces de noyau qui ne sont pas exposées par la bibliothèque standard. (Sous Linux, beaucoup d'entre eux sont proposés via /proc et /sys .)
Et puis il y a les binaires compilés statiquement. Si une mise à jour du noyau casse l'un d'entre eux, la seule solution serait de les recompiler. Si vous avez la source :Linux prend également en charge les logiciels propriétaires.
Même lorsque la source est disponible, tout rassembler peut être pénible. Surtout lorsque vous mettez à jour votre noyau pour corriger un bogue avec votre matériel. Les gens mettent souvent à jour leur noyau indépendamment du reste de leur système car ils ont besoin du support matériel. Dans les mots de Linus Torvalds :
Briser les programmes utilisateur n'est tout simplement pas acceptable. (…) Nous savons que les gens utilisent d'anciens binaires pendant des années et des années, et que faire une nouvelle version ne signifie pas que vous pouvez simplement les jeter. Vous pouvez nous faire confiance.
Il explique également qu'une des raisons d'en faire une règle forte est d'éviter l'enfer des dépendances où vous auriez non seulement à mettre à jour un autre programme pour faire fonctionner un noyau plus récent, mais aussi à mettre à jour un autre programme, et un autre, et un autre , car tout dépend d'une certaine version de tout.
C'est un peu ok pour avoir une dépendance à sens unique bien définie. C'est triste, mais inévitable parfois. (…) Ce qui n'est PAS acceptable, c'est d'avoir une dépendance à double sens. Si le code HAL de l'espace utilisateur dépend d'un nouveau noyau, ce n'est pas grave, même si je soupçonne que les utilisateurs espèrent que ce ne sera pas le "noyau de la semaine", mais plutôt le "noyau des derniers mois".
Mais si vous avez une dépendance à double sens, vous êtes foutu. Cela signifie que vous devez effectuer une mise à niveau en lock-step, et ce n'est tout simplement PAS ACCEPTABLE. C'est horrible pour l'utilisateur, mais plus important encore, c'est horrible pour les développeurs, car cela signifie que vous ne pouvez pas dire "un bogue s'est produit" et faire des choses comme essayer de le réduire avec une bissection ou similaire.
Dans l'espace utilisateur, ces dépendances mutuelles sont généralement résolues en conservant différentes versions de bibliothèque; mais vous ne pouvez exécuter qu'un seul noyau, il doit donc prendre en charge tout ce que les gens pourraient vouloir faire avec.
En relation :Explication de l'ordre de tri ?Officiellement,
la rétrocompatibilité pour [les appels système déclarés stables] sera garantie pendant au moins 2 ans.
En pratique cependant,
La plupart des interfaces (comme les appels système) ne devraient jamais changer et être toujours disponibles.
Ce qui change le plus souvent, ce sont les interfaces qui ne sont destinées qu'à être utilisées par des programmes liés au matériel, dans /sys . (/proc , d'autre part, qui depuis l'introduction de /sys a été réservé aux services non liés au matériel, pratiquement jamais de pannes incompatibles.)
En résumé,
casser l'espace utilisateur nécessiterait des correctifs au niveau de l'application
et c'est mauvais parce qu'il n'y a qu'un seul noyau, que les gens veulent mettre à niveau indépendamment du reste de leur système, mais il existe de nombreuses applications avec des interdépendances complexes. Il est plus facile de maintenir la stabilité du noyau que de maintenir à jour des milliers d'applications sur des millions de configurations différentes.