1 pièce(s) jointe(s)
Linus Torvalds critique le code de test qui reste dans Linux 6.15-rc1
Linus Torvalds critique le code de test resté dans Linux 6.15-rc1 qui ralentit le processus de build :
« N'obligez pas les autres à voir cette chose dégoûtante »
Linus Torvalds, créateur du noyau Linux, a toujours été un défenseur de la qualité du code et de l'efficacité des systèmes. Cependant, récemment, il a exprimé sa frustration à propos de certaines sections du code de test qui ont ralenti le processus de construction dans la version 6.15-rc1 du noyau Linux. Non seulement ces tests ont provoqué des lenteurs indésirables, mais Torvalds a aussi vivement critiqué certaines parties du code DRM (Direct Rendering Manager) qu'il a qualifiées de « dégoûtantes » et de « merde » (turd), exprimant sa colère vis-à-vis de la lente adoption de meilleures pratiques.
Linus Torvalds, en tant que créateur du noyau Linux, a toujours insisté sur le fait que la clarté et l'efficacité sont des priorités pour la gestion du noyau. À chaque nouvelle version du noyau, il se montre souvent critique face à des ajouts ou des modifications qu'il considère comme inutiles ou trop coûteux en termes de performance. Le développement du noyau Linux est un processus complexe, mais Linus veille à ce que chaque changement reste dans l'esprit de la simplicité et de l'efficacité. Cela inclut la gestion de code pour le matériel, les pilotes, les tests et tout autre aspect technique.
Dans la version 6.15-rc1, Linus a relevé plusieurs problèmes avec le code qui ralentissait la construction du noyau. Cela ne signifie pas que les tests sont inutiles, mais plutôt qu’ils doivent être bien conçus pour ne pas nuire à la performance globale. Linus est très clair sur ce point : le code de test est crucial, mais il doit être optimisé pour ne pas devenir un fardeau qui ralentit le développement.
« N'obligez pas les autres à voir cette chose dégoûtante »
En guise de conseil à ses collègues développeurs Linux, Toralds a déclaré : « Si vous voulez faire ce truc hdrtest, faites-le dans le cadre de vos *propres* vérifications. N'obligez pas les autres à voir cette chose dégoûtante et à avoir ces étrons dans leurs arbres ». Il a ensuite indiqué qu'il avait décidé de marquer hdrtest comme cassé pour l'instant, afin d'empêcher son inclusion dans les versions régulières.
Qu'est-ce que « hdrtest » et pourquoi a-t-il porté la frustration de Torvalds à son paroxysme ? L'équipe de développeurs Linux a récemment fusionné une large collection de mises à jour de pilotes de cartes graphiques open-source. Il s'agit notamment du code « hdrtest » pour le pilote du noyau Intel Xe, qui comprend du code pour tester les fichiers d'en-tête DRM (Direct Rendering Manager).
Pour éviter toute confusion, DRM dans ce cas n'est pas Digital Rights Management, mais se réfère au Direct Rendering Manager. Dans le même ordre d'idées, hdrtest n'a rien à voir avec les graphiques HDR (High Dynamic Range), mais est utilisé par les développeurs pour vérifier l'intégrité et le confinement des fichiers d'en-tête DRM.
Voici son message en entier :
« Grr. J'ai fait le pull, j'ai résolu les conflits (triviaux), mais j'ai remarqué que cela a fini par contenir la dégoûtante merde "hdrtest" qui
(a) ralentit la compilation parce qu'il est fait pour une compilation régulière d'allmodconfig au lieu d'être une simple chose que vous pouvez exécuter si nécessaire
(b) laisse des traces de 'hdrtest' dans les répertoires 'include'.
Les gens se sont déjà plaints séparément à ce sujet. Il n'aurait jamais dû arriver jusqu'à moi sous cette forme abîmée.
Pourquoi diable ces tests font-ils partie intégrante de la compilation ?
Et bon sang, nous n'ajoutons pas de fichiers aléatoires pour les dépendances qui rendent l'arbre des sources désagréable.
Ce qui m'a fait remarquer que c'était encore là, c'est que « git status » se plaint que ces stupides turds ne sont pas ignorés.
Mais plus important encore, ces étrons cassent aussi la complétion de nom de fichier ! Donc non, l'ajouter à gitignore ne résout pas vraiment le problème, cela m'aurait juste permis de ne pas le remarquer aussi rapidement.
Cette chose doit *mourir*.
Si vous voulez faire ce truc hdrtest, faites-le dans le cadre de vos *propres* vérifications. Ne faites pas en sorte que tous les autres voient cette chose dégoûtante et aient ces étrons dans leurs arbres.
Je vais juste le désactiver en le marquant BROKEN pour l'instant. Vous pouvez décider de ce que vous voulez faire, mais non, forcer les autres à voir ces choses n'est pas la solution.
Je suggérerais de ne *pas* l'intégrer à la configuration de Kconfig et à la compilation normale, mais de faire en sorte que *vous* puissiez l'exécuter dans le cadre de vos tests (c'est-à-dire de le faire en tant que « make drm-hdrtest », et non dans le cadre des compilations normales).
Linus »
La culture de la qualité du code dans la communauté Linux
L’incident récent avec les tests et le code DRM illustre bien la culture de qualité du code au sein de la communauté Linux. Chaque contribution au noyau est scrutée de près, et les modifications qui affectent les performances ou la stabilité du système sont souvent rejetées. Torvalds et d'autres leaders de la communauté n'hésitent pas à être francs et directs lorsqu'il s'agit de maintenir la qualité du code. Cela peut parfois conduire à des tensions, mais c'est également un des moteurs du succès du projet Linux.
Dans l'écosystème Linux, les tests sont cruciaux pour assurer la robustesse et la stabilité du système d'exploitation. Cependant, il est tout aussi important de s'assurer que ces tests n'entravent pas le développement et qu'ils sont adaptés aux besoins réels du projet. De plus, le code relatif au matériel, en particulier les pilotes et le gestionnaire de rendu direct, nécessite une attention particulière en raison de son impact direct sur les utilisateurs finaux.
La gestion rigoureuse du code source de Linux et la critique constructive de Torvalds servent de modèle pour le développement open-source en général. Ces commentaires sont un appel à la responsabilité de la part des développeurs : écrire un code de qualité, garder à l'esprit les performances du système, et ne jamais laisser des morceaux de code inefficaces ou inutiles s’infiltrer dans les versions publiques du noyau.
Ce n'est pas la première fois qu'il sort de ses gonds
Linus Torvalds est de plus en plus frustré par le matériel bogué et les attaques théoriques du processeur
Il a participé récemment à un fil de discussion portant sur la possibilité d'éviter d'utiliser barrier_nospec() dans la fonction copy_from_user(). Lors des échanges, Linus Torvalds a déclaré que l'utilisation de cette macro a un impact négatif sur les performances du noyau. La conversation a évolué vers des discussions sur le comportement du processeur et la meilleure façon de le gérer, les différents comportements/exigences avec les nouveaux CPU Intel supportant le Linear Address Masking (LAM), et les maux de tête généraux autour des atténuations de la sécurité du CPU.
Linus Torvalds a indiqué que certains codes suggérés ne fonctionnent probablement pas pour les CPU Intel avec LAM comme Arrow Lake et Lunar Lake. Cependant, en l'absence de certitude sur le comportement de certains processeurs, il a été suggéré de modifier préventivement certains codes du noyau. C'est là que Linus Torvalds a écrit une réponse tard dans la nuit. Il n'a pas hésité à fustiger les fabricants de matériel dans un style classique qu'on lui connaît :
Citation:
Envoyé par Linus Torvalds
Honnêtement, j'en ai assez du matériel bogué et des attaques complètement théoriques qui n'ont jamais été utilisées dans la pratique.
Je pense donc que cette fois-ci, nous allons faire pression sur les responsables du matériel et leur dire que c'est *LEUR* foutu problème, et s'ils ne peuvent même pas se donner la peine de dire oui ou non, nous nous contenterons de nous asseoir sur nos lauriers.
Parce que bon sang, mettons la responsabilité là où elle se trouve, et ne nous contentons pas de prendre n'importe quelle merde aléatoire d'un mauvais matériel et de dire « oh, mais ça *pourrait* être un problème ».
Linus Torvalds appelle en effet les fabricants de matériels à s'impliquer davantage dans la sécurité du noyau Linux. Après les commentaires de Linus Torvalds, l'ingénieur d'Intel Kirill Shutemov a fait un commentaire sur ce fil de discussion : « LAM apporte ses propres problèmes de spéculation qui seront résolus par LASS. Il y avait un correctif pour désactiver LAM jusqu'à l'arrivée de LASS, mais il n'a jamais été appliqué pour une raison quelconque ».
LASS (Linear Address Space Separation) est une extension de sécurité qui empêche les accès spéculatifs à l'espace d'adressage virtuel entre le mode utilisateur et le mode noyau. Ce code du noyau est un autre sujet que les discussions que Linus Torvalds a eues sur le fait d'éviter barrier_nospec() dans copy_from_user().
Linus Torvalds fustige un contributeur de Google au noyau Linux
Le débat portait sur l'utilisation des "inodes" comme identifiants uniques pour les métadonnées d'un système de fichiers. Un nœud d'index ou inode (contraction de l'anglais index et node) est un identifiant unique pour un élément spécifique de métadonnées dans un système de fichiers. En d'autres termes, un inode est une structure de données contenant des informations à propos d'un fichier ou répertoire stocké dans certains systèmes de fichiers. Les inodes ont fait l'objet d'un débat, avec des échanges "robustes" entre Linux Torvalds et un Googler appelé Steven Rostedt.
Dans un fil de discussion intitulé "Have the inodes all for files and directories all be the same" (les inodes pour les fichiers et les répertoires doivent-ils être identiques ?), les participants ont fait remarquer que les inodes pouvaient encore jouer un rôle lors de l'utilisation de la commande tar pour l'archivage des fichiers. La discussion a déclenché une réponse du créateur de Linux. Torvalds n'est pas d'accord avec cette idée et a répondu que les inodes avaient fait leur temps. Il estime que les inodes ont peut-être eu un passé "merveilleux", mais ils ont désormais perdu de leur importance et ont été fortement dépassés.
« Oui, les numéros d'inodes étaient spéciaux, et il y a une histoire derrière cela. Cependant, nous devrions nous efforcer de nous éloigner de cette histoire révolue. Un numéro d'inode n'est tout simplement plus un descripteur unique. Nous ne vivons plus dans les années 1970 et les systèmes de fichiers ont changé », a-t-il écrit. Mais le débat sur les inodes s'est poursuivi. Le Googler a suggéré que les inodes devraient tous avoir des numéros uniques. La réponse de Torvalds a utilisé un langage et un ton rarement vus ces dernières années. En réponse à la suggestion de Rostedt, Torvalds s'est laissé aller et a déclaré :
« Arrêtez de rendre les choses plus compliquées qu'elles ne doivent l'être. Et bon sang, ARRÊTEZ DE COPIER LES FONCTIONS DE LA COUCHE VFS. C'était une mauvaise idée la dernière fois, c'est une très mauvaise idée cette fois-ci aussi. Je n'accepte pas ce genre de conneries ». La principale critique de Torvalds à l'égard de l'approche de Rostedt est que le Googler ne comprenait pas entièrement le sujet, ce que Rostedt a reconnu plus tard. Mais entre-temps, Torvalds l'avait incendié comme suit : « vous avez copié cette fonction sans comprendre pourquoi elle fait ce qu'elle fait, et votre code est donc un déchet ».
Conclusion
La récente critique de Linus Torvalds à propos du code de test et du code DRM dans la version 6.15-rc1 du noyau Linux met en lumière l'importance de la rigueur et de la qualité dans le développement de logiciels open-source. Si les tests sont essentiels pour garantir la fiabilité du système, ils doivent également être optimisés pour éviter de devenir un frein au processus de développement. De même, le code relatif au matériel, comme celui du gestionnaire de rendu direct, doit être exempt de mauvaises pratiques et de code mal structuré.
Le message de Linus Torvalds est clair : l’efficacité et la qualité doivent toujours primer. Les développeurs doivent constamment remettre en question la qualité de leur code et s’efforcer de l’améliorer, car chaque ligne de code dans le noyau Linux est un élément fondamental pour assurer la stabilité, la performance et la sécurité du système.
Source : Linus Torvalds
Et vous ?
:fleche: Les tests devraient-ils être séparés du code principal pour éviter d'alourdir le processus de compilation ? Si oui, comment gérer leur intégration ?
:fleche: Quel rôle les tests automatisés jouent-ils dans le processus de développement du noyau Linux, et à quel point peuvent-ils être "lourds" sans affecter négativement l'efficacité du processus de développement ?
:fleche: Linus Torvalds adopte une approche assez directe pour critiquer le code. Est-ce une méthode efficace pour motiver les développeurs à améliorer leur code, ou cette approche pourrait-elle avoir des effets négatifs sur la dynamique de la communauté ?
:fleche: Comment évaluer l’impact des lenteurs de compilation ou des tests sur l’expérience des utilisateurs finaux du noyau Linux, et jusqu’où les compromis doivent-ils être faits pour optimiser la performance du système ?
