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 !

L'un des responsables de la maintenance du noyau Linux Rust se retire du projet, invoquant des "absurdités non techniques"

Le , par Jade Emy

70PARTAGES

10  0 
L'un des responsables de la maintenance du noyau Linux Rust a annoncé se retirer du projet. La raison est qu'il n'a "plus l'énergie et l'enthousiasme" pour répondre à certaines "absurdités non techniques". Le projet Rust pour le noyau Linux est considéré comme prometteur, mais il n'est pas sans complications, notamment la gestion des Pull Request.

Rust est un langage de programmation généraliste qui met l'accent sur les performances, la sécurité des types et la concurrence. Il assure la sécurité de la mémoire, c'est-à-dire que toutes les références pointent vers une mémoire valide, sans ramasse-miettes. Depuis 2015, Rust a été adopté par des entreprises telles qu'Amazon, Discord, Dropbox, Google (Alphabet), Meta et Microsoft. En décembre 2022, il est devenu le premier langage autre que le C et Assembly à être pris en charge dans le développement du noyau Linux.

Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5, voire la soixantaine. Linus Torvalds, le créateur du noyau Linux lui-même a souligné qu'"il est vraiment difficile de trouver des personnes qui sont des mainteneurs". C'est pourquoi, le projet Rust for Linux est né. L'objectif n'est pas de réécrire le noyau entier du Linux en Rust, mais plutôt d’ajouter du nouveau code, écrit en Rust. Rust pourrait ainsi apporter des bénéfices en termes de qualité, de performance et de sécurité du code du noyau, tout en réduisant les coûts de développement et de maintenance.

Lors de l'édition 2023 du Kernel Maintainers Summit, la communauté a dressé un bilan du projet Rust-for-Linux, le décrivant comme prometteur, mais pas sans complications. L'un des défis des développeurs du projet étant les nombreux Pull Request ajoutant du code Rust important.

Mais Wedson Almeida Filho, l'un des responsables du noyau Rust pour Linux, a décidé de se retirer du projet. Cette décision serait motivée, du moins en partie, par la nécessité de faire face à l'augmentation des "absurdités non techniques" liées à l'utilisation du langage de programmation Rust dans le noyau Linux.


Wedson a écrit sur la liste de diffusion du noyau Linux :

Il s'agit d'une série aussi courte que possible : je me retire du projet Rust pour Linux en tant que responsable de la maintenance.

Je me retire du projet. Après presque 4 ans, je n'ai plus l'énergie et l'enthousiasme que j'avais autrefois pour répondre à certaines absurdités non techniques, il est donc préférable de laisser cela à ceux qui l'ont encore en eux.

À l'équipe de Rust for Linux : merci, vous êtes formidables. Ce fut un plaisir de travailler avec vous tous ; les moments que nous avons passés à discuter de questions techniques, à trouver des moyens de résoudre les problèmes de solidité, etc. ont toujours été quelque chose que j'ai apprécié et que j'attendais avec impatience. Je me considère chanceux d'avoir collaboré avec un groupe aussi [talentueux] et amical.

Je souhaite que le projet soit couronné de succès.

Je crois sincèrement que l'avenir des noyaux passe par des langages à mémoire sécurisée. Je ne suis pas un visionnaire, mais si Linux n'intériorise pas cela, je crains qu'un autre noyau ne lui fasse ce qu'il a fait à Unix.

Enfin, je vais laisser un petit échantillon de 3min 30s pour le contexte : https://youtu.be/WiPp9YEBV0Q?t=1529 -- et pour réitérer, personne n'essaie de forcer quelqu'un d'autre à apprendre Rust ni d'empêcher les refactorisations de code C. »
Voici la vidéo pour le contexte :


Wedson est un ingénieur de Microsoft qui a été prolifique dans ses contributions au code Rust pour le noyau Linux au cours des dernières années. Wedson a travaillé sur de nombreuses fonctionnalités du noyau Linux Rust et a même réalisé un portage expérimental du pilote du système de fichiers EXT2 vers Rust. Mais il en a eu assez et se retire maintenant des efforts de Rust pour Linux.

S'il est regrettable de voir Wedson se retirer des efforts de Rust pour Linux, au moins il y a plusieurs autres mainteneurs qui continuent à superviser l'effort pour permettre l'utilisation du langage de programmation Rust dans le noyau Linux.

Source : Annonce de Wedson

Et vous ?

Quel est votre avis sur cette annonce ?

Voir aussi :

Rust dans le noyau Linux: un projet prometteur, mais pas sans complications. La communauté dresse un bilan, lors de l'édition 2023 du Kernel Maintainers Summit

Linus Torvalds exprime sa déception de voir le faible taux d'adoption de Rust comme langage de programmation pour le noyau Linux, car les principaux mainteneurs du noyau sont plus habitués au langage C

L'enquête Rust révèle que les utilisateurs de Linux et de VS Code sont plus nombreux à cibler WebAssembly. La France se situe à la cinquième place mondiale en nombre de développeurs Rust

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

Avatar de denisys
Membre chevronné https://www.developpez.com
Le 03/09/2024 à 18:59
Remonté contre les habitués du C qui freinent les mises à jour de la base de code du noyau vers Rust
Pour faire une bonne vinaigrette.
Il faut de l’huile et du vinaigre !!!!


A mon point de vue, ce n’est qu’une question de temps et de génération.
Ma génération, qui a étais élevé au bon code en C et C++, vers la fin du siècle dernier (1992).
Les jeunes et futures générations qui intégrerons et compileront plus facilement le code en Rust.

Moi, quand j’ai commencé à développer, le Java Scripte n’existais pas.
Aujourd’hui, tous les jeunes savent coder en Java Scripte.

Haaa !!!
Il ne faut pas oublier, non plus, que le créateur de PHP a conçu ce langage en C, parce que il en avait marre de répéter les mêmes routines en C, pour construire des pages Internet , a l’époque.

C’est une question de temps, uniquement !!!
13  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 03/09/2024 à 20:00
Cette "mégalomanie" existe dans toutes les équipes qui sont formattés à travailler avec un langage informatique. Vous allez dans les banques où on fait du COBOL, les développeurs rabaisseront ceux qui font du Java pour sa syntaxe, ceux qui font du Java rabaisseront ceux qui font du NodeJS/TypeScript pour son manque de typage runtime, ceux qui font du NodeJS/TypeScript rabaisseront ceux qui font du Python pour ses performances, et généralement tout le monde excepté ceux qui font du PHP rabaisseront PHP

Il faut aller au-delà de cela, de cette passion qui nous anime pour un langage informatique, parce que oui nous avons appris, travaillé et en quelque sorte "grandi" avec un certain langage, et on arrive d'ailleurs à reconnaitre les générations grâce à leur formation universitaire Pascal, C++, Java, et plus récemment Python... Et je comprends aussi que certains en ait marre d'apprendre le dernier langage à la mode (je pense personnellement aux langages JVM tels que Scala complètement mort et Kotlin propulsé par IntelliJ+Google suite au procès d'Oracle en ayant fait du Java), ce qui me perturbe c'est que Rust soit considéré comme une mode ou bien les goûts syntaxiques évoqués par certains pour ne pas adopter le Rust. Rust est basé sur le retour d'expérience des langages existants, il existe des raisons pour laquelle Rust inclu/limite des features, comme pourquoi il n'y a pas d'héritage à plusieurs niveaux, pourquoi on continue à utiliser le point-virgule etc (je ne vais pas rentrer dans les détails ici)

Un langage informatique est un outil, ce n'est pas votre enfant ou votre animal de compagnie, l'affect n'a pas lieu d'être. Il faut citer les "vrais" avantages et inconvénients techniques de Rust pour être juste, Rust n'est pas parfait : moins de libraries contrairement à Go qui est supporté par Google (quelqu'un sait s'il existe un driver Sybase en Rust ? ), lent à compiler etc... mais en tant qu'expert seriez-vous capable de me citer des langages libres (compilateur inclu) qui sont à la fois memory-safe, null-safe, thread-safe et qui ne requirent pas une VM que l'on doit installer et qui doit gérer un système de ramasse-miettes ?

Bref, pour en revenir à Linux, bien que le C soit un langage simple et très apprécié, ce dernier ne respecte pas les critères cités au-dessus (je vous invite à regarder les taux des failles de sécurités causés par l'absence du memory-safe ou null-safe), donc qui maintiendra aussi bien le noyau lorsque Linus Torvalds ne sera plus de ce monde ?
7  0 
Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 03/09/2024 à 21:20
Citation Envoyé par Gugelhupf Voir le message
Cette "mégalomanie" existe dans toutes les équipes qui sont formattés à travailler avec un langage informatique.
Je dirais même: Cette "mégalomanie" existe dans toutes les équipes qui sont formatées à travailler avec un seul langage informatique.

Citation Envoyé par Gugelhupf Voir le message
Un langage informatique est un outil, ce n'est pas votre enfant ou votre animal de compagnie, l'affect n'a pas lieu d'être. Il faut citer les "vrais" avantages et inconvénients techniques de Rust pour être juste,
Je ne suis que partiellement d'accord. Je pense personnellement qu'il y a une forme d'art à concevoir et écrire du code. Il y a tout simplement quelque chose de plaisant et d'harmonieux à voir les patterns se former, les couches communiquer. Il y a de la beauté dans certaines expressions épurées.

Et dès le moment où ce n'est plus seulement un outil ou un travail alimentaire, alors les goûts de tous entrent en considération, un peu comme pour la musique et pour tant d'autres sujet ou soudain tout le monde a un avis extrêmement tranché sur ce qui est bien et ce qui ne l'est pas.

J'aime bien la syntaxe de Rust, mais ça doit venir du fait que j'ai pratiqué plusieurs langages assez différents au lieu de me spécialiser dans un seul, et du coup, mes goûts personnels ont évolué avec chaque langage et la philosophie qu'il portait.

J'essaye toujours de choisir mes outils en fonction des avantages qu'ils vont me procurer, mais il y aura toujours certains outils qui me plairont plus que d'autres pour une question de goûts personnels, sur un périmètre donné.

Bien entendu, quand on collabore sur un projet, il faut être capable de faire des compromis, comme sur le style par exemple, pour garder une base de code maintenable et compréhensible.

Je pense que le gros souci, là, c'est qu'il y a deux langages avec une philosophie différente, et sur deux périmètres différents: un est à l'origine de l'ensemble du noyau, l'autre n'est utilisé que pour certains modules (souvent nouveaux), et c'est peut-être vu par certains développeurs comme du code de seconde zone - d'où le manque d'effort et d'engouement de leur part.

Et le gars de redox_os fait un peu le malin dans son tweet et en profite pour se faire de la pub, mais je suis certain que si demain, ses nouveaux modules étaient développés en Lua (pour gagner du temps sur la compilation, puisque tu as évoqué le temps de compilation de Rust) avec le reste en Rust, il y aurait la même animosité de la part d'une partie de ses développeurs, et peut-être une forme de mépris.

Désolé pour le pavé, mais ta réponse m'a inspiré!
7  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 31/08/2024 à 9:02
Il y a bien sur un système de lib standard comme dans tous les langages, la particularité de Rust est qu'il y en a deux :
  • "core" contient juste le minimum pour que le langage fonctionne (type et traits de base).
  • "std" reprend "core et ajoute les fonctionnalités qui dépendent de l'OS (fichier, réseau, allocation mémoire, thread, processus, ...), et quelques types plus avancée (collection, chemins, ...). On reste loin de l'exhaustivité des bibliothèques Java ou Python.


Quand on développe un programme dans des environnements ou l'on a pas accès normal à l'OS (création d'OS, un driver, l'embarqué sans OS), on utilise le mode "nostd" où l'on à plus accès qu'à core. C'est l'équivalent du mode freestanding en C. Le cas du développement de drivers Linux en Rust est un exemple typique de code où l'on utilise le mode nostd.

Ceci dit la grande majorité des programmes Rust finaux utilisent la bibliothèque "std" classique qui donne accès aux fonctionnalités générales de l'OS, en utilisant parfois la libc en interne, vu que c'est le seul moyen stable qu'offrent la plupart des OS pour ce faire.
6  0 
Avatar de OuftiBoy
Membre éclairé https://www.developpez.com
Le 30/08/2024 à 12:38

Avant que les les défenseurs acharnés de Rust ne me tombe dessus, je précise que je n'ai rien contre ce dernier, qui pour ce que j'en ai vu, est très prometteur, même si je ne suis pas enthousiasmé personnellement par ce dernier (mais ce n'est pas le sujet).



Je comprend les anciens mainteneurs de longue date, qui ont accompli (en C) un travail de dingue sur le noyau.

Ils n'ont rien contre Rust, mais il faut comprendre et accepter qu'ils n'ont pas envie (à leur âge), de continuer.

Je pense que tout le monde est d'accord pour dire que la récriture complète du noyau linux en Rust, n'est pas une bonne idée. Techniquement, je peux comprendre que de nouveaux ajouts soit fait en [B]Rust[/R], mais cela pose certains problèmes:

  • Deux langages différents dans une base de code, ça complexifie la chaîne de production.

  • Y'a-t-il suffisamment de développeurs très compétents en Rust pour garantir l'évolution et la maintenance d'un projet de cette envergure ?

  • Si la balance se fait vers Rust, qui voudra bien assurer la maintenance du vieux code C ?

  • Si certains nouveaux contributaires veulent qu'on accepte d'introduire Rust dans la base de code, ils doivent aussi accepter de maintenir et permettre d'évoluer tout ce qui est et restera en C


Je ne suis pas spécialiste en Rust, mais j'ai lu (désolé, je n'ai pas noté les références) que bon nombres du code Rust de bas niveau se fait en mode unsafe, pour contourner la rigidité de Rust sur certaines parties de ce code. Et, dites-moi si je me trompe, Rust en mode unsafe, n'apporte pas grand chose au niveau sécurité par rapport au C. Je peux donc comprendre la réticences de bon nombres d'excellents développeurs C qui ne jugent pas nécessaires/souhaitable d'ajouter la complexité d'une base de code utilisant 2 langages.

Les "Pro Linux" (Perso, je ne suis ni Pro, ni Contre), n'ont eu de cesse de dire (à juste tire), que Linux était meilleur, plus stable, moins sujet aux vulnérabilités que d'autres OS. Et pourtant, tout cela a été fait en C...

BàV et Peace & Love
4  0 
Avatar de floyer
Membre confirmé https://www.developpez.com
Le 01/09/2024 à 8:07
Citation Envoyé par 23JFK Voir le message
En plus la compilation n'est pas simplifiée puisqu'il faut à présent compiler deux codes sources différents pour avoir un kernel fonctionnel... Les amateurs LFS vont adorer.
Il vont taper make au lieu de make…
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 03/09/2024 à 10:35
Citation Envoyé par VBurel Voir le message
Non, le "C" permet de tout faire, y compris les couches que rajouteraient les langages de plus haut niveau pour sécuriser la mémoire.
Permettre de tout faire, ne veut pas dire que c'est l'outil idéal pour tout faire. Si tu veux rajouter assez de couches au C pour le sécuriser aussi bien que Rust, tu vas juste créer un nouveau langage.
C'est d'ailleurs plus ou moins comme ça qu'est né Rust, quand Mozilla s'est rendu compte que sécuriser complètement le C++ introduisait tellement de limitations et d'incompatibilités avec l'existant qu'un nouveau langage était plus logique, il se sont intéressé au projet personnel d'un de leur employés.

Citation Envoyé par VBurel Voir le message
La sécurisation de la mémoire dépend essentiellement du programmeur et des outils qu'il a mis en place. Avoir des fonctions d’allocations sécurisées est très facile à faire.
C'est tellement simple que, même dans les OS, les bases de données et les navigateurs dont la sécurité est particulièrement surveillée, plus des deux tiers des vulnérabilités sont causées par des erreurs mémoires.

Citation Envoyé par VBurel Voir le message
Développer des langages pour intégrer une partie du travail (sécurisation) ou de l’organisation (++) du développeur est une perte de temps monumental pour l’informatique au sens large.
C'est en effet une perte de temps quand on a sa disposition une armée de développeurs de génie, parfaitement formés et surtout qui ne font jamais la moindre erreur.
Mais dans le monde réel, ça ne marche pas..
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 04/09/2024 à 23:03
Citation Envoyé par OuftiBoy Voir le message
Si de nouveaux mainteneurs veulent introduire (ce qui n'est pas interdit) le Rust c'est à eux qu'ils revient la charge d'une bonne introduction.
Et c'est exactement le cas. L'introduction de Rust a été faite de manière prudente en limitant Rust a des modules isolés. Les gens qui travaillent sur Rust4Linux ne demandent pas aux contributeurs qui ne sont pas intéressés par les modules en Rust de lire, ni d'écrire la moindre ligne de Rust.
A priori, la seule chose qui leur a été demandée c'est, dans certains cas, d'expliciter les règles que doivent actuellement respecter l'API des drivers, bref des choses qui sont de toute façon nécessaire pour faire des drivers C corrects et qui auraient dues être officiellement documentées. Le système de type de Rust permettra d'assurer que ces contraintes soient respectés, corrigeant en partie le problème du manque de documentation des API actuelles.

Citation Envoyé par OuftiBoy Voir le message
Quand je lis: Les principaux mainteneurs du noyau sont plus habitués au langage C et veulent poursuivre sur cette lancée. Ils refusent donc de porter le code existant en Rust ou de passer du temps pour aider d’autres contributeurs à le porter en Rust. Je suis tout à fait d'accord avec eux.
Ce qui tombe bien, car on ne leur demande pas, même si certains se plaignent comme si c'était le cas

Citation Envoyé par OuftiBoy Voir le message
Les mainteneurs historique ne veulent pas aider d'autres contributeurs à le porter en Rust. Ils sont là pour coder ces vieux développeurs barbus, ils ne sont pas des instituteurs ou des formateurs pour expliquer à d'autres comme faire un portage vers un autre langage qu'une nouvelle génération veut utiliser.
On ne leur demande évidement pas non plus des cours magistraux de C. Les gens qui travaillent sur Rust4Linux connaissent bien évidement le C.

Citation Envoyé par OuftiBoy Voir le message
On parle ici des développeurs extrêmement expérimentés du noyaux. S'il considèrent que Rust n'apportent pas de plus-value significativement au kernel on peut quand même prendre leur opinion au sérieux, me semble-t-il ?
On peut les écouter attentivement, sans pour autant prendre tout ce qu'ils disent pour parole d'évangile. Je suis prêt a entendre que le Rust pourrait poser plus de problèmes qu'il apporte de solution, mais pour le moment les arguments avancés ne sont généralement pas pertinents. Particulièrement pour ceux qui sont virulents, j'entends plus une résistance de principe que de vrais arguments. Quand j'entends le mainteneur dire qu'il ne veut pas de la religion du Rust, je pense que c'est assez symptomatique de sa vision et qu'il défend lui même la religion du C sur une base plus dogmatique que pragmatique.

Citation Envoyé par OuftiBoy Voir le message
Voilà une partie très intéressante. Je reprend les chiffres donnés: 2288 en 20 ans. 2288/20 = 144,4. 15,9% de ces vulnérabilités à des problèmes lié au C (gestion mémoire, dépassement de tampons, allocation non libérées, accà des zones mémoire invalide ou libérée, etc)
15,9% c'est juste pour le dépassement de tampon, ce qui n'est qu'une partie des erreurs de sécurité mémoires. J'ai pas de chiffres dont je suis certain pour le cas particulier de Linux, mais de ce qu'on constate en général sur les grosses applications C on est généralement au dessus de 60% de failles majeures dues à la sécurité mémoire. Si on en crois ce site, sur les dernières années plus de 99% des failles sont dues à la sécurité mémoire.

Citation Envoyé par OuftiBoy Voir le message
Bien, certains benchmarks, disent que Rust. Mais de combien de % sont-elles plus "rapide" ? Pas de grand chose, et d'autres benchmarks disent le contraire.
En effet l'approche la plus correcte au niveau des performance, c'est de considérer que Rust et C sont en moyenne aussi rapides.

Citation Envoyé par OuftiBoy Voir le message
Une partie de ces "atouts" sont annihilés par le fait qu'il faut passer en mode "unsafe" pour certains accès au noyau. Et donc une partie de l'avantage de Rust s'évapore à cause de ce passage en mode "unsafe" qu'il est forcé d'utiliser à certains endroits.
L'existence du bloc unsafe n’annihile absolument pas tout l’intérêt de Rust. Le fait de contenir les risques de sécurité mémoire dans des petites sections clairement identifiées et donc plus facile a surveiller efficacement, reste un énorme avantage comparé à un langage qui est unsafe partout.

Citation Envoyé par OuftiBoy Voir le message
Je peux les comprendre... Quand il faut créer des "passerelles", ça ajoute une couche de complexité. Puisque ces "passerelles" sont apparement nécessaires pour l'introduction du code Rust dans le noyau, c'est à eux que revient cette chargent, et pour se faire, ils doivent être aussi compétant en C qu'en Rust.
Et c'est justement le cas.

Citation Envoyé par OuftiBoy Voir le message
Je ne connais pas ce projet @redox_os, mais s'il a fallut 30 ans pour que Linux soit ce qu'il est aujourd'hui, je doute fort que @redox_os le fasse en quelques années seulement.
Bien évidement qu'on ne va pas refaire Linux à l'identique avec 10 fois moins de temps et de contributeurs. Il n’empêche que Redox est d'une qualité surprenante au vu de son jeune age et de son équipe limitée. De là à dire que Rust peut aider à développer du code de qualité plus vite, il y a un pas que je ne franchirais pas encore, mais je laisse la question en suspens.

Citation Envoyé par OuftiBoy Voir le message
Faut-il comprendre que pour certaines parties, Rust ne fait pas le taf ?
Même Linux n'est pas 100% en C, il contient de l'assembleur.
A ma connaissance le noyau de Redox est bien en Rust et le bootloader est en assembleur. Bien évidement les applications de l'espace utilisateur ne sont pas toutes en Rust. Beaucoup sont des portages d'application C (GCC, make, curl, ...)

Citation Envoyé par OuftiBoy Voir le message
Quand au fait de parler de faire passer vos changements devant des mégalomanes pédants et condescendants (je redis que je ne connaît pas cette communauté), et que de cela découle le fait de créer un nouveau noyaux (ou OS complet, je ne sais pas), montre en tout cas très peu d'humilité, mais également un sentiment de supériorité face à des gens qui ont fait leurs preuves depuis 30 ans.
Ce n'est certainement qu'une des raisons qui l'ont poussé a créer Redox OS, qui n'est pas un Linux réécrit en Rust, mais un OS structurellement très différent. C'est un micro-kernel, qui a la base ne visait pas la compatibilité directe avec POSIX, bien qu'il semble changer sur ce point.

Pour le reste je vais pas répondre sur tout au point par point parce que c'est très long et certain trucs sont beaucoup trop confus, ce qui est n'est pas vraiment votre faute vu que vous commentez la série de petites citations de l'article qui manquent énormément de contexte.

Citation Envoyé par OuftiBoy Voir le message
Et bien qu'il continue son travail sur cet outils, qui, d'après lui même n'est pas terminé. Puis il pourra avancer.
C'est évident, mais cette charge de travail revient à ceux qui veulent introduire Rust, et donc à la communauté Rust
Encore une fois personne ne dit l'inverse. Le projet Rust4Linux essaie de mettre en place toute l'infrastructure pour qu'écrire un driver en Rust soit le plus naturel possible et s’intègre au mieux dans l'existant. Le statut est toujours expérimental et tout n'est pas encore prêt mais ça n’empêche pas le travail d'avancer sans avoir d'impact négatif sur les développeurs actuel, a par les inciter à mettre au clair les éléments actuellement mal documentés de l'API, ce qui est une bonne chose même pour les drivers C.

Citation Envoyé par OuftiBoy Voir le message
Ce processus de mise à niveau finira par s'arrêter et une version minimale de Rust sera définie une fois que les fonctionnalités importantes dont dépend le noyau se seront stabilisées.
Cest du bon sens. Le noyau linux ne peut pas être construit sur un langage qui évolue toujours en permanance. Rust n'est pas "prêt" actuellement, laissons-le se stabiliser avant de l'intégrer dans un si grand projet.
Rust est stable (dans le sens rétrocompatible) depuis presque 10 ans, mais il continue d'évoluer et n'a pas de raisons de s’arrêter. Ca n'est pas un problème, au contraire, vu qu'il manque encore certaines fonctionnalité pour s'intégrer plus efficacement au noyau.

Citation Envoyé par OuftiBoy Voir le message
Ojeda a déclaré qu'il travaillait à la recherche de ressources de développement pour gccrs ; le projet repose actuellement sur plus de 800 correctifs hors arborescence et a encore beaucoup de travail à faire en plus...
Il n'y a peut-être pas autant de développeurs compétant que de développeurs C compétant. Rust est encore jeune.
C'est un plutôt le contraire, gcc étant écrit en C++, y compris le nouveau frontend pour Rust en cours de développement. La difficulté c'est surtout qu'il faut des développeurs qui maitrisent les arcanes de gcc et motivés pour y ajouter un fontend en Rust. Le compilateur de référence ne manque pas de contributeurs compétants.
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 30/08/2024 à 16:49
Citation Envoyé par imperio Voir le message
Pourquoi ne pas partir à la retraite dans ce cas ? Pour l'avenir du projet, il vaut mieux permettre d'utiliser un langage plus récent (qui correspond aux besoins du projet) car il y aura plus de développeurs maitrisant ce langage. C'est l'argument principal de Linus pour pousser Rust dans le kernel (en plus des avantages fournis par Rust).
Pour le coup, pousser des gens très compétents à la retraite s'il ne le souhaitent pas me parait un problème. Si c'est comme ça qu'on présente sérieusement l'introduction de Rust, il ne faut pas s'étonner que les gens le traitent comme une menace plutôt qu'une opportunité.
Il reste clairement assez de C a écrire pour des dizaines d'années, les experts barbus ne sont pas encore tous bon pour l'ANPE Pole Emploi France travail.

Citation Envoyé par imperio Voir le message
C'est un but long terme. Si une partie fonctionne, je ne pense pas qu'ils la réécriront avant un bon moment.
Ce n'est clairement pas un but annoncé en tout cas. Rien n’empêche que ça le devienne à l'avenir, mais le seul objectif pour le moment est de permettre de faire des modules en Rust qui s’intègrent dans la base existante.

Citation Envoyé par imperio Voir le message
Non. C'est pour appeler du code C ou alors pour appeler des intrinsics que les blocks unsafe sont nécessaires. Et dans le kernel linux, c'est plutôt commun le C.
Dans les drivers et les OS, il y a quand même des usages particuliers du unsafe, par exemple pour permettre d'écrire à des endroits fixes de la mémoire, ou faire de l'assembleur pour accéder a des fonctionnalités particulières des processeurs, ...

Citation Envoyé par imperio Voir le message
Hé bien oui, tu te trompes, même assez lourdement. Le code unsafe n'enlève pas les vérifications de Rust, par-contre ça te permet d'appeler des fonctions unsafe (donc des fonctions C notamment) et de déréférencer un pointeur. Ce sont grosso-modo les seules différences. Je ne sais pas trop pourquoi les gens pensent que l'unsafe enlèvent magiquement tous les checks de Rust...
En même temps certaines fonction unsafe comme "transmute" pouvant casser à peu prêt toute la sécurité offerte par le typage, je comprend comment on peut en venir a cette conclusion. Ce qu'il faut retenir c'est surtout que les blocs unsafe restent rares et permettent d'identifier simplement le code à risque et donc de réduire son usage au minimum.
3  0 
Avatar de Astraya
Membre émérite https://www.developpez.com
Le 31/08/2024 à 10:48
Citation Envoyé par Uther Voir le message
Il y a bien sur un système de lib standard comme dans tous les langages, la particularité de Rust est qu'il y en a deux :
  • "core" contient juste le minimum pour que le langage fonctionne (type et traits de base).
  • "std" reprend "core et ajoute les fonctionnalités qui dépendent de l'OS (fichier, réseau, allocation mémoire, thread, processus, ...), et quelques types plus avancée (collection, chemins, ...). On reste loin de l'exhaustivité des bibliothèques Java ou Python.


Quand on développe un programme dans des environnements ou l'on a pas accès normal à l'OS (création d'OS, un driver, l'embarqué sans OS), on utilise le mode "nostd" où l'on à plus accès qu'à core. C'est l'équivalent du mode freestanding en C. Le cas du développement de drivers Linux en Rust est un exemple typique de code où l'on utilise le mode nostd.

Ceci dit la grande majorité des programmes Rust finaux utilisent la bibliothèque "std" classique qui donne accès aux fonctionnalités générales de l'OS, en utilisant souvent la libc en interne, vu que c'est le seul moyen stable qu'offrent la plupart des OS pour ce faire.
Pour être précis, le core n'utilise pas de heap, I/O et tout ce qui en découlent. C'est vraiment le strict minimum du langage, c'est tout ce que le langage est ( tableau statique, référence, liftetime) c'est vraiment pour le pur embarquée, c'est comme du C sur des systèmes sans heap.

`std` est dépendant du système sur lequel il tourne ( il y a donc une implémentation spécifique au système pour `std` comme #ifdef _WIN32). Et donc std peut fournir tout ce que 'core' ne fournit pas.

Un 3ème crate est le crate `alloc`, qui fournit un moyen de gérer les allocations dynamiques. Le crate `std` utilise le crate `alloc` qui gère l'allocation dynamique avec le système sur lequel `std` tourne aka std::alloc) en fournissant une allocateur globale.

Toutes les librairies que j'ai faite en Rust sont ![no_std] même si je ne faut pas d'embarquer, car souvent je n'est juste pas besoin de heap ( hashage principalement) ou demandant de fournir un alloc.
3  0