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 :
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 ».
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 ».
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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
