Linus Torvalds, ingénieur logiciel, créateur principal et développeur du noyau Linux, a annoncé le 25 avril la sortie de la version 5.12 du kernel Linux. Cette version apporte un certain nombre d'améliorations notables pour divers matériels, notamment la prise en charge de l'hyperviseur ACRN et la prise en charge de l'écriture NFS Eager. Cette version du noyau permet également de sélectionner le modèle de préemption au démarrage de l'ordinateur. Actuellement, l'utilisation d'un modèle de préemption none/voluntary/model est une option de configuration au moment de la construction.Dans son message du 25 avril portant sur la sortie de la version 5.12 du kernel Linux, Linus Torvalds a indiqué que dans l’ensemble, les améliorations apportées au nouveau kernel ne sont pas assez nombreuses. « ...merci à tous ceux qui ont rendu la semaine dernière très calme, ce qui avec la sortie de la version 5.12 du kernel Linux me rendent encore plus heureux. Il ajoute que malgré la semaine de grâce supplémentaire, il s'agit d'une version relativement petite dans l'ensemble ». Voici, ci-dessous, les améliorations apportées à la version 5.12 du kernel Linux.
Mappage d'ID dans les montages
Cette version introduit le concept de montages idmapped. Cela permet de mapper l'ID utilisateur d'un montage à un autre. Cela permet de partager plus facilement des fichiers entre plusieurs utilisateurs ou plusieurs machines, notamment dans des scénarios complexes. Par exemple, les montages idmapped seront utilisés dans l'implémentation des répertoires personnels portables dans systemd-homed.service où ils permettent aux utilisateurs de déplacer leur répertoire personnel vers un périphérique de stockage externe et de l'utiliser sur plusieurs ordinateurs auxquels sont attribués des UID et des GID différents. Cette implémentation est fournie avec des portages pour les systèmes de fichiers FAT et ext4, d'autres systèmes de fichiers étant annoncés dans les prochaines versions.
Permettre de sélectionner le modèle de préemption au démarrage et à l'exécution
Actuellement, l'utilisation d'un modèle de préemption none/voluntary/model est une option de configuration au moment de la construction. Cette version ajoute les options de démarrage preempt=none/voluntary/full (par défaut : full), pour permettre aux distributions de construire un noyau PREEMPT mais de revenir à un comportement d'ordonnancement au démarrage proche de PREEMPT_VOLUNTARY (ou PREEMPT_NONE) via une sélection au démarrage. Il y a aussi le commutateur /debug/sched_debug pour faire cela au moment de l'exécution. Cette fonctionnalité est implémentée par le biais de patches d'exécution (une nouvelle variante des appels statiques).
Prise en charge de l'hyperviseur ACRN
Cette version ajoute la prise en charge de l'hyperviseur ACRN. ACRN est une pile d'hyperviseur de référence de type 1, s'exécutant directement sur le matériel, et convient à une variété de solutions pour l’Internet des objets et des dispositifs embarqués. Elle met en œuvre une architecture VMM hybride, utilisant un service VM privilégiée. Le service VM gère les ressources système (CPU, mémoire, etc.) et les périphériques d'E/S des VMs User. Plusieurs utilisateurs VM sont pris en charge, chacun d'entre eux exécutant Linux, Android OS ou Windows.
Prise en charge de l'écriture NFS Eager
Cette version ajoute un ensemble d'options de montage pour les systèmes de fichiers NFS qui contrôlent la façon dont les appels système write() réagissent. writes=lazy est la valeur par défaut, et conserve le comportement actuel. writes=eager signifie que l’écriture est immédiatement envoyée comme une écriture instable au serveur. writes=wait signifie que l'écriture est envoyée comme une écriture instable, puis une réponse est attendue. Cela garantit qu'un client NFS voit immédiatement les erreurs ENOSPC.
Recherche de chemin non bloquant lors de l'ouverture d'un fichier
Cette version supporte les recherches de noms de chemin qui ne se bloquent en aucun cas. Cela signifie que le noyau essaiera de résoudre le chemin avec les données en cache, mais s'il doit effectuer des E/S, il retournera une erreur. Ceci est nécessaire pour io_uring(), mais le support dans openat2() avec le paramètre RESOLVE_CACHED a été aussi ajouté.
Interrogation NAPI basée sur les threads du noyau
NAPI est une fonctionnalité de mise en réseau qui interroge le périphérique réseau au lieu d'attendre les demandes, car cela améliore les performances pour les charges à haut débit. Cette interrogation, cependant, s'exécute dans le contexte de softirq, où le planificateur de tâches ne peut pas la voir, et il est difficile de régler le système pour une performance maximale. Dans cette version, l'interrogation peut être configurée pour être effectuée par un thread du noyau. Ces threads du noyau sont visibles par l'espace utilisateur et le planificateur de tâches, qui peut prendre de meilleures décisions par lui-même, et cela permet d'affecter un thread du noyau à des processeurs spécifiques.
La suppression d'un certain nombre de sous-architectures Arm 32 bits, des instructions atomiques pour BPF, les recherches conditionnelles de fichiers avec LOOKUP_CACHED, la prise en charge des blocs de périphériques dans le système de fichiers Btrfs, le mappage des ID de systèmes de fichiers, la prise en charge de la construction du noyau avec l'optimisation du temps de liaison Clang, l'outil de débogage du noyau KFENCE sont les améliorations fortes apportées à la version 5.12.
Prise en charge de Rust pour le développement du noyau Linux
Le mois dernier, le tout premier support permettant l'utilisation du langage de programmation Rust dans le noyau Linux est apparu dans l'arbre Linux-Next pour des tests plus étendus avant son inclusion éventuelle dans le noyau principal. Même si les auteurs de ce travail jugent qu'il ne s'agit pas d'un ajout significatif, cela jette les bases de la construction des fonctionnalités du noyau Rust pour l'avenir. Ce support est conditionné par la présence d'un compilateur Rust (rustc) sur le système. De ce fait, les architectures actuellement visées sont ARM64 et x86_64.
L'année dernière, les développeurs du noyau Linux semblent s'être mis d'accord sur le sujet. Pour mémoire, Rust est plébiscité, car il offre plusieurs avantages, notamment en ce qui concerne la mémoire. Les partisans de Rust ont cité des travaux qui montrent qu'environ deux tiers des vulnérabilités du noyau auxquelles ont été attribués des CVE sur Android et Ubuntu sont tous liés à des problèmes de sécurité de la mémoire.
Plus tôt ce mois, Miguel Ojeda, développeur du noyau, a lancé une proposition de RFC sur la liste de diffusion du noyau Linux. Le message de la liste de diffusion décrit les convictions des développeurs impliqués dans l'ajout du code Rust au noyau, les avantages tels que l'amélioration de la sécurité de la mémoire, et plus encore. « Certains d'entre vous ont remarqué ces dernières semaines et ces derniers mois qu'une tentative sérieuse d'apporter un second langage au noyau était en train de se forger. Nous y sommes enfin, avec une RFC qui ajoute le support pour Rust au noyau Linux », a déclaré Miguel Ojeja. « Nous savons qu'il y a des coûts et des risques énormes à introduire un nouveau langage dans le noyau », a-t-il ajouté.
La semaine dernière, c’est Linus Torvalds qui a lancé les débats au sujet de la prise en charge de Rust dans le développement du noyau Linux. En effet, le créateur principal et développeur du noyau Linux a déclaré lors d’une interview que des discussions sur le sujet seraient beaucoup plus importantes qu'un avis de Google sur le langage. Interrogé sur la suggestion d'un internaute qui a indiqué que, « la solution ici est simple : il suffit d'utiliser C++ au lieu de Rust », Linus Torvalds n'a pas pu se retenir et aurait traité le C++ de « langage de merde ».
« Pour les personnes qui n'aiment pas le C, optez pour un langage qui vous offre réellement quelque chose de valable. Par exemple, les langages avec sécurité de la mémoire, qui peuvent éviter certains des dangers du C, ou les langages qui facilitent la gestion de la mémoire. Toute personne qui dit réécrire le noyau en C++ est trop ignorante », avait ajouté Torvalds.
Pour certains analystes, cette prise en charge du noyau ne sera pas possible pour Linux 5.13. Peut-être avec Linux 5.14 ou une autre version du noyau plus tard dans l'année.
Source : Liste de diffusion
Et vous ?
Utilisez-vous une distribution Linux ? Laquelle ? Quelle amélioration du kernel Linux vous intéresse le plus ?Voir aussi :
Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google La prise en charge de Rust pour le développement du noyau Linux fait l'objet d'une nouvelle série de discussions, après une proposition de RFC La prise en charge de Rust pour le développement du noyau Linux commence à prendre forme, le langage fait un premier pas vers la branche "Linux-Next" Linux : Greg Kroah-Hartman refuse les excuses via lettre ouverte des chercheurs impliqués dans le scandale des « commits hypocrites », ou d'introduction secrète de vulnérabilités au noyau