IdentifiantMot de passe
Loading...
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 !

Linus Torvalds aux développeurs du noyau : « grandissez et arrêtez de faire des demandes d'extraction juste avant la date limite »,
La première version candidate de Linux 6.1 est disponible

Le , par Bill Fassinou

8PARTAGES

7  0 
Linus Torvalds a publié dimanche la première version candidate de Linux 6.1 (Linux 6.1-rc1) avec le support initial de Rust, l'ajout de MGLRU et la prise en charge de nouveaux matériels. La version stable de Linux 6.1 devrait arriver en décembre et sera probablement la version du noyau de Linux LTS de cette année. Torvalds a également lancé un appel aux développeurs pour qu'ils lui facilitent la vie en ajoutant du code plus tôt dans le cycle de développement. Il demande à chaque développeur de préparer le code qu'il souhaite ajouter à la nouvelle version du noyau avant l'ouverture de la fenêtre de fusion.

La fenêtre de fusion de deux semaines qui s'est ouverte avec la publication du noyau Linux 6.0 le 2 octobre est maintenant officiellement fermée et il est temps d'avoir un avant-goût de la prochaine version majeure, le noyau Linux 6.1. Linux 6.1-rc1 est prêt pour les testeurs, les adopteurs précoces et les utilisateurs à la pointe de la technologie qui veulent avoir un aperçu de ce qui sera inclus dans la version stable, qui est attendu pour le début ou la mi-décembre 2022 (soit le 4 décembre ou le 11 décembre). Comme cela a été annoncé depuis un moment, la plus grande nouveauté de Linux 6.1 est probablement la fusion du code de l'infrastructure Rust.



Cela rend possible le développement de pilotes dans un autre langage que le C. Toutefois, bien que cela semble très excitant pour les développeurs Rust, il ne s'agit que d'une mise en œuvre très basique du support pour le langage Rust qui ne peut pas être utilisé pour des cas d'utilisation réels pour le moment. Pendant la fenêtre de fusion, Linux 6.1 a ajouté de nombreuses autres fonctionnalités excitantes, notamment : MGLRU a été fusionné pour offrir un potentiel de performance significatif, en particulier pour les systèmes à mémoire limitée, et le travail sur le nouveau support graphique Intel Arc Graphics et AMD RDNA3 a été poursuivi.

En outre, KMSAN (Kernel Memory Sanitizer) a ajouté. KMSAN est un détecteur dynamique d'erreurs de mémoire pour le noyau Linux. Il fournit une solution rapide et complète pour trouver les bogues d'utilisation après la libération et hors limites. Entre autres nouveautés de Linux 6.1, Linux x86_64 émettra un avertissement par défaut sur les mappages W+X et AMD Platform Management Framework a fusionné, imprimant les cœurs de CPU où les défauts de segmentation se produisent. Cette dernière fonctionnalité aurait permis de détecter tous les débordements de tampon basés sur memcpy de ces dernières années, et bien plus encore.

Torvalds estime que le nouveau noyau Linux 6.1 pourrait recevoir jusqu'à huit versions candidates. « Cette version ne s'annonce pas particulièrement importante : nous n'avons "que" 11 500 commits non fusionnés pendant cette fenêtre de fusion, contre 13 500 la dernière fois. Donc pas exactement minuscule, mais plus petit que les dernières versions. Au moins en nombre de commits », a déclaré Torvalds. Une autre chose importante est la série de VM LRU multi-gen. Par ailleurs, puisque ce sera la dernière version majeure du noyau Linux de l'année, elle devrait également être la prochaine série LTS (Long-Term Support).

Enfin, Torvalds a profité de l'occasion pour demander aux développeurs du noyau d'être plus "proactifs" à l'avenir afin qu'il n'ait pas trop de choses à gérer à la fin de la fenêtre de fusion. « Laissez-moi juste dire qu'après avoir réglé ma machine et rattrapé la fenêtre de fusion, j'ai été quelque peu frustré par les demandes d'extraction tardives. Je l'ai déjà mentionné, mais c'est vraiment assez ennuyeux de recevoir un certain nombre de demandes d'extraction dans les derniers jours de la fenêtre de fusion », explique Torvalds. Il a offert des conseils sur la façon dont les développeurs de noyaux peuvent faire les choses correctement.

« Oui, la fenêtre de fusion est de deux semaines, mais c'est surtout pour me laisser le temps d'examiner les choses, pas pour "deux semaines pour mettre en place à la hâte une branche que vous enverrez à Linus le vendredi de la deuxième semaine". L'idée de "faire une nuit blanche pour rendre le papier la veille de la réunion" est quelque chose qui aurait dû disparaître après le lycée. Pas pour le développement de noyaux. La règle est que les choses qui me sont envoyées doivent être prêtes *avant* l'ouverture de la fenêtre de fusion, pas pendant la fenêtre de fusions », a déclaré dimanche Torvalds dans son message.

Il a ajouté : « avec un peu de mou pour "la vie arrive", bien sûr, mais j'ai vraiment l'impression que quelques personnes traitent la fin de la fenêtre de fusion comme une date limite, manquant l'ensemble "il était censé être prêt avant la fenêtre de fusion" ». Torvalds a reconnu que ce n'est pas la première fois qu'il dit cela, mais aimerait que ce soit la dernière. Il espère que plus de développeurs pourraient le prendre à cœur cette fois.

Source : Linus Torvalds

Et vous ?

Que pensez-vous des nouveautés de Linux 6.1-rc1 ?
Quel est votre avis sur les plaintes de Torvalds à propos des développeurs qui font tardivement des demandes d'extraction ?

Voir aussi

L'inclusion de Rust for Linux à la version 6.1 du noyau est désormais en cours comme souhaité par Linus Torvalds, et va rendre possible le développement de pilotes dans un autre langage que le C

Linus Torvalds annonce officiellement le noyau Linux 6.0, cette version introduit la prise en charge de l'architecture matérielle AArch64

Rust for Linux est officiellement fusionné, le support initial de Rust for Linux fournit l'infrastructure de base et une intégration élémentaire

Un premier aperçu de Rust dans le noyau 6.1, avec Jonathan Corbet, « il n'y aurait pas encore assez de Rust dans le noyau pour faire quoi que ce soit d'intéressant », estime-t-il

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

Avatar de yannoo95170
Membre régulier https://www.developpez.com
Le 17/10/2022 à 23:49
« Oui, la fenêtre de fusion est de deux semaines, mais c'est surtout pour me laisser le temps d'examiner les choses, pas pour "deux semaines pour mettre en place à la hâte une branche que vous enverrez à Linus le vendredi de la deuxième semaine". L'idée de "faire une nuit blanche pour rendre le papier la veille de la réunion" est quelque chose qui aurait dû disparaître après le lycée. Pas pour le développement de noyaux. La règle est que les choses qui me sont envoyées doivent être prêtes *avant* l'ouverture de la fenêtre de fusion, pas pendant la fenêtre de fusions » a déclaré dimanche Torvalds dans son message.

Pourquoi ne pas mettre en place une fenêtre d'une ou 2 semaines de propositions/analyses de branches **AVANT** l'ouverture de la fenêtre de fusion ?
7  0 
Avatar de smarties
Membre expert https://www.developpez.com
Le 20/11/2022 à 11:20
Quand on voit les tweets, c'est certain que RUST apporte énormément de fiabilité pour de la programmation système.

Je ne suis pas sur de la pertinence d'un transcompilateur car cela peut produire des choses difficilement compréhensibles.

Les bibliothèques système peuvent aussi être écrites en RUST et utilisées pour tout.

Avoir le C et RUST pour le noyau complexifie probablement mais si on peut avoir des éléments de qualité, performants, stables et sécurisés il faut continuer l'intégration progressive de RUST.
5  0 
Avatar de CoderInTheDark
Membre émérite https://www.developpez.com
Le 03/11/2022 à 9:00
Il y a du progrès, si il n'a pas utiliser de "fuck" ou autre nom d'oiseau.
Mais il a raison.

C'est ce genre de comportement qui oblige à rajouter des règles, alors qu'il faudrait que les gens soient raisonnables et se disent que tout ajout de dernière minute à des conséquence pour le groupe.

A part ça même après le lycée ça m'arrivait de finir à la dernière minute, et je detestais ça

Quand j'étais comptable la pérriode d'inventaire ressemblait aussi à ça, un gros stresse pour boucler et retomber sur des pièces au dernier moment
2  0 
Avatar de destroyedlolo
Membre actif https://www.developpez.com
Le 16/12/2022 à 15:10
"des mainteneurs pour le noyau Linux risque d’aller croissant si son développement se poursuit en langage C."

Ben voyons
C'est juste le langage le plus utilisé dans les OS (au sens large, démons, DE, ...) inclus, l'embarqué et une bonne partie des applications les plus utilisées.

Alors s'il est difficile de trouver de bons programmeurs C(++), le C a encore de beaux jours devant lui.
"Bon" pas dans le sens "connaisseur du C", mais bon dans le sens "qui maitrise l'algorithmie, ne font pas du code crade, respectent les ressources" : Les enseignements basés autour de langages plus permissifs tel que Python ou Java font que le code qu'ils pondent est au mieux "passable" dès que le langage ne corrige pas toutes leurs lacunes.
3  1 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 18/12/2022 à 10:36
c'est arrivé récemment, donc très peu. tout le code C ne va pas être réécrit en Rust, mais au fur et à mesure du temps ça va augmenter.
2  0 
Avatar de d_d_v
Membre éprouvé https://www.developpez.com
Le 14/12/2023 à 14:15
Citation Envoyé par 23JFK Voir le message
J'ai plutôt l'impression que les dev C n'ont pas envie de réecrire du code qui fonctionne à peu près alors que les dev Rust sont eux très motivés pour réinventer la roue en mieux.
En mieux...ou pas !
2  0 
Avatar de 23JFK
Membre expert https://www.developpez.com
Le 12/12/2022 à 19:21
J'ai plutôt l'impression que les dev C n'ont pas envie de réecrire du code qui fonctionne à peu près alors que les dev Rust sont eux très motivés pour réinventer la roue en mieux.
1  0 
Avatar de smarties
Membre expert https://www.developpez.com
Le 12/12/2022 à 22:04
Citation Envoyé par 23JFK Voir le message
J'ai plutôt l'impression que les dev C n'ont pas envie de réecrire du code qui fonctionne à peu près alors que les dev Rust sont eux très motivés pour réinventer la roue en mieux.
L'intégration RUST avec Cargo est beaucoup plus pratique que le C. Réécrire des bibliothèque permet aussi de se faire la main sur le langage.

Je ne suis pas spécialement pour une réécriture de toutes les bibliothèques mais certaines gagneraient en lisibilité, performance et/ou fiabilité.
1  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 18/12/2022 à 10:38
Presque rien en fait. Les noyau 6.1 (et suivants) ont juste mis a disposition une API Rust pour permettre de commencer le développement de drivers en Rust qui interagissent de manière propre avec le cœur du noyau en restera en C.
Quand des drivers écrits en Rust auront atteint un niveau de qualité suffisamment avancé pour être intégré au projet, ils pourraient le rejoindre, mais ça ne sera probablement pas le cas avant un moment.
1  0 
Avatar de fdecode
Membre régulier https://www.developpez.com
Le 13/12/2023 à 10:28
Je me permets de poster un complément important à ce vieux message que je ne peux plus éditer:
Citation Envoyé par fdecode Voir le message
Les références et références mutables de rust sont des pointeurs (des pointeurs bas-niveau, pas des pointeurs "intelligents" dont l'usage est controlé par la sémantique du langage.
Mais en Rust il est tout à fait possible de travailler sur les pointeurs de manière non-contrôlée, tout simplement en utilisant le mode unsafe { ... }.
C'est découragé, c'est vrai, mais vous pouvez même faire de l'arithmétique de pointeurs en vue d'un adressage non contrôlé de la mémoire.
Même la sacrosainte interdiction de dupliquer les références mutables peut être contournée, comme le montre l'exemple suivant:
Si cette interdiction est sacrosainte, c'est que c'est un comportement indéfini (UB), et il ne faut surtout pas utiliser ce contournement.
Dans cet exemple précis, le compilateur peut faire de l'optimisation de code en utilisant l'information de mutabilité de la référence, ce qui peut induire des résultats imprédictibles si on a transgressé les règles de mutabilité.
Ces optimisations peuvent être comparées à ce que permet le mot clef `restrict` en C.
1  0