IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Linux 4.3 passe en disponibilité générale
Après une nouvelle diatribe de Linus Torvalds sur un code qu'il a qualifié « de merde »

Le , par Michael Guilloux
27 commentaires

10PARTAGES

8  1 
La version stable de Linux 4.3 est généralement disponible après sept releases candidates (RC). Mais comme d’habitude, le « seigneur » de Linux a encore fait preuve de « tolérance zéro », après avoir découvert une sorte d’incompétence dans le travail des développeurs du noyau, quelques jours avant la sortie.

Comme l’explique Linus Torvalds dans la liste de diffusion du noyau Linux (LKML), cette nouvelle version embarque un éventail de changements et améliorations. Il met particulièrement en évidence une mise à jour du code réseau et la correction d’un bogue du mode vm86. Linux 4.3 est arrivé avec moins d’incidents, à part le nouveau code dans net/ipv6/ip6_output.c que Linus a trouvé un peu plus éprouvant pour les nerfs. En effet, quelques jours avant la sortie officielle, Linus Torvalds n’a pas manqué de qualifier de merde, le nouveau code dit « amélioré ».

Ci-dessous l'ancien code.
Code : Sélectionner tout 
mtu -= hlen + sizeof(struct frag_hdr);
Ci-dessous le nouveau code.
Code : Sélectionner tout 
1
2
3
if (overflow_usub(mtu, hlen + sizeof(struct frag_hdr), &mtu) ||
mtu <= 7)
goto fail_toobig;
À propos du nouveau code, Linus s’indigne : « le code ci-dessus est de la merde, et il génère du code de merde. Il semble mauvais, et il n’y a aucune raison pour cela. » Torvalds critique le fait que ce code « utilise des trucs de fantaisie qui nécessitent un support pour un compilateur magique intégré », pour ne citer que cette seule critique. Sans indexer des personnes en particulier, il continue pour dire que quiconque croit qu’un tel code est lisible, efficace (même avec le support du compilateur magique), et particulièrement sûr, « est tout simplement incompétent et à côté de la plaque ». « Débarrassez-vous de cela. Et je ne veux plus jamais voir cette merde », a-t-il conclu en parlant du code. Il propose donc un nouveau code qu’il estime meilleur avec le même nombre de lignes, et qui « n’utilise pas de fonctions auxiliaires folles dont personne ne sait ce qu'elles font, et qui rend beaucoup plus clair ce qu’il fait. »

Ci-dessous le code proposé par Linus Torvalds.
Code : Sélectionner tout 
1
2
3
if (mtu < hlen + sizeof(struct frag_hdr) + 8)
goto fail_toobig;
mtu -= hlen + sizeof(struct frag_hdr);
La nouvelle version de Linux vient par ailleurs avec un support pour les graphiques fournis par les processeurs Skylake d’Intel et R9 Fury d’AMD. Le support pour le système de fichiers EXT3 a quant à lui disparu, sans trop de douleur pour les utilisateurs étant donné qu’il s’agit d’un sous-ensemble de EXT4. Linux 4.3 accorde également un intérêt particulier aux bureaux virtuels Linux avec un support OpenGL 3.3 pour VMware. On note non seulement des mises à jour de pilotes ainsi que de nouveaux pilotes, mais encore quelques autres corrections dans ARM.

Comme à l’accoutumée, la fin du développement de cette version annonce également l’ouverture d’un nouveau cycle de développement, ici Linux 4.4. Si la version 4.3 n’est pas une version LTS (support à long terme), Linus Torvalds annonce à l’avance que Linux 4.4 en sera une.

Sources : Sortie de Linux 4.3, LKML, Git Kernel.

Et vous ?

Que pensez-vous des changements et nouveautés dans Linux 4.3 et de la nouvelle critique de Linus Torvalds ?

Voir aussi

Forum Linux

Une erreur dans cette actualité ? Signalez-nous-la !

27 commentaires
Commenter Signaler un problème
Pierre Louis Chevalier
Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 02/11/2015 à 16:21
Historiquement ca à toujours été difficile pour les personnes brillantes de travailler avec une bande de médiocres.
6  0 
Neckara
Avatar de Neckara
Inactif https://www.developpez.com
Le 03/11/2015 à 12:44
Je mettrais ma main à couper que c'est exécuté en mode kernel.

Dans ce cas là, un goto est parfaitement acceptable, ce qui ne veut pas dire qu'il faut en abuser et l'utiliser n'importe comment.

Certains codes sont contraints et on se retrouve obligé à faire du code moins portables, à réduire la lisibilité du code pour des problèmes de performances, etc.
En mode kernel, les goto sont parfois la meilleure chose à faire, pour les performances, mais aussi parfois pour la lisibilité et la sécurité du code. Ce n'est pas pour rien que les goto sont assez fréquents dans ce genre de code.

Mais c'est un contexte particulier et contraint.
6  0 
Chuck_Norris
Avatar de Chuck_Norris
Membre émérite https://www.developpez.com
Le 02/11/2015 à 16:08
Je suis d'accord avec Linus, le code en question est de la merde.

Utiliser une fonction pour une simple comparaison, c'est nuire à la lisibilité. Cela oblige à aller rechercher le code source de la fonction, alors que le test écrit directement est plus clair et plus court. En plus de ça, cet appel de fonction prend un pointeur vers une variable, dont la valeur est ensuite également testée dans le même if : même si c'est légal cela reste confus et de plus cela peut empêcher certaines optimisations.
3  0 
anykeyh
Avatar de anykeyh
Membre confirmé https://www.developpez.com
Le 02/11/2015 à 17:29
Voici la version originale, je la trouve beaucoup moins violente pour les personnes, et il se focalise sur le code en lui meme. Et je suis d'accord avec lui en passant:


Christ people. This is just sh*t

.The conflict I get is due to stupid new gcc header file crap. But what makes me upset is that the crap is for completely bogus reasons.

This is the old code in net/ipv6/ip6_output.c:

mtu -= hlen + sizeof(struct frag_hdr);

and this is the new “improved” code that uses fancy stuff that wants magical built-in compiler support and has silly wrapper functions for when it doesn’t exist:

if (overflow_usub(mtu, hlen + sizeof(struct frag_hdr), &mtu) ||

mtu <= 7)

goto fail_toobig;

and anybody who thinks that the above is (a) legible (b) efficient (even with the magical compiler support) (c) particularly safe is just incompetent and out to lunch.

The above code is sh*t, and it generates shit code. It looks bad, and there’s no reason for it.

The code could *easily* have been done with just a single and understandable conditional, and the compiler would actually have generated better code, and the code would look better and moreunderstandable. Why is this not

if (mtu < hlen + sizeof(struct frag_hdr) + 8)

goto fail_toobig;

mtu -= hlen + sizeof(struct frag_hdr);

which is the same number of lines, doesn’t use crazy helper functions that nobody knows what they do, and is much more obvious what it actually does. I guarantee that the second more obvious version is easier to read and understand. Does anybody really want to dispute this?

Really. Give me *one* reason why it was written in that idiotic way with two different conditionals, and a shiny new nonstandard function that wants particular compiler support to generate even half-way sane code, and even then generates worse code? A shiny function that we have never ever needed anywhere else, and that is just compiler-masturbation.

And yes, you still could have overflow issues if the whole “hlen +xyz” expression overflows, but quite frankly, the “overflow_usub()“ code had that too. So if you worry about that, then you damn well didn’t do the right thing to begin with.

So I really see no reason for this kind of complete idiotic crap.

Tell me why. Because I’m not pulling this kind of completely insane stuff that generates conflicts at rc7 time, and that seems to have absolutely no reason for being an idiotic unreadable mess.

The code seems *designed* to use that new “overflow_usub()“ code. It seems to be an excuse to use that function.

And it’s a f*cking bad excuse for that braindamage.

I’m sorry, but we don’t add idiotic new interfaces like this for idiotic new code like that.

Yes, yes, if this had stayed inside the network layer I would never have noticed. But since I *did* notice, I really don’t want to pull this. In fact, I want to make it clear to *everybody* that code like this is completely unacceptable. Anybody who thinks that code like this is “safe” and “secure” because it uses fancy overflow detection functions is so far out to lunch that it’s not even funny. All this kind of crap does is to make the code an unreadable mess with code that no sane person will ever really understand what it actually does.

Get rid of it. And I don’t *ever* want to see that shit again.

Linus
3  0 
Chuck_Norris
Avatar de Chuck_Norris
Membre émérite https://www.developpez.com
Le 03/11/2015 à 18:43
Citation Envoyé par Laurent 1973 Voir le message
Qu'est ce que ce chiffre 8 ?
Même si de manière générale je suis d'accord sur les nombres magiques, ici on parle clairement de MTU, si la notion relative à ce 8 est complexe à expliquer (et donc à expliciter dans un nom de constante) et que tout le monde sait que c'est 8 et ça ne peut qu'être 8, alors autant écrire 8 plutôt que de créer une constante à 20 caractères pour définir quelque chose qui ne sera jamais autre chose que 8. A ce niveau-là je parlerai de tolérance vu que le nom de la variable auquel ce 8 est comparé permet de savoir clairement de quoi on parle. Et je préfère largement trouver "8" qu'une constante "EIGHT".

Citation Envoyé par Laurent 1973 Voir le message
l'ordre d’évaluation
A ma connaissance le noyau est en C, et l'ordre d'évaluation (+ prioritaire à < est commun à de nombreux langages. Je vois mal surcharger de parenthèses (et donc nuire à la lisibilité) simplement parce que certains langages exotiques (dans lequel jamais aucun module noyau ne sera écrit) ont une priorité différente.

Citation Envoyé par Laurent 1973 Voir le message
Et sinon, autre remarque: il serait bien que Linus prennent quand même des leçons de diplomatie, autant sur le font il a raison, autant sur la forme il a loupé sa communication.
Je préfère un noyau efficace grâce au talent d'un codeur génial et grincheux plutôt qu'un noyau inefficace écrit par un codeur charismatique mais médiocre.

Citation Envoyé par robertledoux Voir le message
Toute façon, venant d'un type qui utilise "goto"... Autant le premier code ne check rien, autant celui de Torvalds est une merde infâme.
Le premier code utilisait déjà le goto pour commencer donc c'est malvenu de mettre ça sur le dos de Linus, et ensuite de nombreux ouvrages affirment que goto est toléré dans la gestion d'erreur (ce qui est le cas ici) si les gérer d'une autre manière nuit à la lisibilité globale du code ou à la performance. De plus, il n'y a pas d'exception en C, et de toute manière la gestion d'exceptions à un coût qu'on ne peut pas se permettre au niveau noyau.

Citation Envoyé par nirgal76 Voir le message
A mon taf, ça passe pas la revue de code.
Chaque entreprise a ses standards de code. De plus je doute qu'on puisse comparer le développement d'un noyau au développement de logiciel lambda.

Citation Envoyé par FranT Voir le message
J'imagine la tête des profs qui rabâchent d'année en année à leurs étudiants que faire du goto est un sacrilège !!!
Les professeurs sont là pour enseigner de bonnes pratiques pour éviter les mauvais départs, mais les beaux principes de la fac doivent parfois s'effacer devant la réalité du terrain, et c'est bien plus souvent qu'on croit.

Dans ce cas que devrais-je dire du Pacman écrit en Java par les professeurs à l'époque où j'étais sur les bancs de l'école, où ils ont poussé les "bonnes pratiques" tellement à l'extrême (tout objet dans ce cas précis) que le jeu ramait énormément même sur les machines les plus puissantes de l'époque.

Citation Envoyé par Jipété Voir le message
J'ai fait un test tout bête :
Je ne pense pas que la complexité de ton test soit comparable à celle d'un extrait du code noyau. Après, il est évident que les compilateurs sont de plus en plus doués pour générer du code efficace quelle que soit la structure de langage utilisée.
3  0 
Kropernic
Avatar de Kropernic
Expert confirmé https://www.developpez.com
Le 03/11/2015 à 9:52
Moi je trouve qu'il a raison de s'exprimer de cette manière tant qu'il ne s'en prend pas à la personne qui a écrit le code directement.

C'est ok de dire "T'as écrit un code de merde" mais pas "T'es qu'un con incapable d'écrire un code correct".

En étant "brut", les remarques formulées marque l'esprit des gens et ils les retiennent. En étant mielleux, il y a 80% de chance que la même erreur soit reproduite.

My 2 cents.
2  0 
youx21
Avatar de youx21
Membre du Club https://www.developpez.com
Le 02/11/2015 à 16:07
Sincèrement je pense que j'aurais du mal à travailler avec un type pareil, mais son code est tout de même nettement plus lisible. Rien à voir
2  1 
Laurent 1973
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 02/11/2015 à 17:07
Citation Envoyé par Michael Guilloux Voir le message

Ci-dessous le nouveau code.
Code : Sélectionner tout 
1
2
3
if (overflow_usub(mtu, hlen + sizeof(struct frag_hdr), &mtu) ||
mtu <= 7)
goto fail_toobig;
...
Ci-dessous le code proposé par Linus Torvalds.
Code : Sélectionner tout 
1
2
3
if (mtu < hlen + sizeof(struct frag_hdr) + 8)
goto fail_toobig;
mtu -= hlen + sizeof(struct frag_hdr);
Je trouve en effet aussi que le code de Linus est plus claire que le précédent.

Je me permettrais quand même de rajouter 2 réserves (n'en déplaise à Linus):
  1. Qu'est ce que ce chiffre 8 ?
    L'age de ma nièce? le nombre de cartes de cœur dans un jeu de 32? Nombre d'octets minimal?
    En général, on évite de laisser ce genre de numéro magique dans un code et on le remplace par un constante (un "define" c'est bien en c++, c'est remplacé à la compilation) qui permet d'explicité la valeur.
  2. l'ordre d’évaluation
    A quoi est équivalent (mtu < hlen + sizeof(struct frag_hdr) + 8)?
    à (mtu < (hlen + sizeof(struct frag_hdr) + 8)) ou à ((mtu < hlen) + sizeof(struct frag_hdr) + 8)
    En c++, il me semble que le '+' est prioritaire sur le '<'.
    Ce n'est pas le cas de tout les langages, la précision permettrait de lever le doute et d'améliorer aussi la lisibilité.

Comme quoi, on peut en dire sur juste 3 lignes de codes

Et sinon, autre remarque: il serait bien que Linus prennent quand même des leçons de diplomatie, autant sur le font il a raison, autant sur la forme il a loupé sa communication.
2  1 
Jipété
Avatar de Jipété
Expert éminent sénior https://www.developpez.com
Le 03/11/2015 à 12:49
Yop !

Citation Envoyé par robertledoux Voir le message
Toute façon, venant d'un type qui utilise "goto"...
Citation Envoyé par nirgal76 Voir le message
du "goto",
Citation Envoyé par FranT Voir le message
A la première lecture, le goto m'a fait drôle et je ne m'attendais pas à ça de la part d'une sommité comme Linus.
J'imagine la tête des profs qui rabâchent d'année en année à leurs étudiants que faire du goto est un sacrilège !!!
Comme quoi...
Citation Envoyé par webtb Voir le message
des goto.
Ça risque de partir en troll HS mais ça m'énerve, à force, cette discrimination du goto...

en Delphi/Lazarus/Pascal tout le monde va applaudir :
Code : Sélectionner tout 
1
2
if x => CONST then proc_grandX;
// suite avec x < à CONST
et là tout le monde va hurler :
Code : Sélectionner tout 
1
2
if x => CONST goto proc_grandX;
// suite avec x < à CONST
Et elle est où la différence ?
Bon, syntaxiquement parlant, il faut un then dans mon second exemple sinon le compilo va crier très fort, mais c'est du pseudocode et c'est pour illustrer.

Merci de m'éclairer.
2  1 
Washmid
Avatar de Washmid
Membre averti https://www.developpez.com
Le 02/11/2015 à 16:25
D'accord avec lui également. Ce genre de & dans ce contexte (un test) c'est un nid de bug infâme.
0  0 
Commenter Signaler un problème