Il y a beaucoup de choses à mettre en place avant de pouvoir écrire le premier pilote. Il faut mettre en place les outils nécessaires pour la compilation et intégrer avec le système de build existant.
Pour tirer profit de Rust il faut définir beaucoup d'interfaces pour faire le lien entre le code C et Rust afin d'avoir un modèle cohérent entre les deux et pouvoir communiquer ensemble sans broncher.
C'est assez fastidieux et les premiers bénéfices ne sont pas très visibles au début, surtout qu'en général les premiers tests se font souvent sur des pilotes ou composants légers où le gars de l'écriture en Rust est difficile à réellement estimer.
Cela rend tout le travail de ce petit monde long, pas très agréable d'autant que l'accueil par les développeurs en place est de fait froid, cela peut créer des frictions pour le travail en C actuel (car si une structure change, le code Rust pour faire l'interface doit être adaptée).
C'est donc une situation difficile jusqu'à que la situation se stabilise et que Rust quitte l'état d'expérimentation dans le noyau Linux pour faire partie intégrante du noyau sur le long terme. C'est d'autant plus gênant que jusqu'à cette étape il y a des difficultés. LLVM ne gère pas toutes les architectures que le noyau Linux gère jusqu'à présent. Les outils de compilations du noyau dans les différentes distributions ou chaine de compilation (type Yocto ou buildroot) sont bien impactés par son introduction du moins si certains composants rendent Rust obligatoires. Et beaucoup de développeurs du noyau ne connaissent pas vraiment Rust ce qui rend la cohabitation forcément problématique pour la revue des correctifs ou pour corriger du code Rust qui dépend sur du code C qui est changé.
Je pense en effet qu'introduire Rust ne peut se faire que dans une optique de progressivement remplacer le code C existant jusqu'à qu'il disparaisse presque complètement. Mais cela sera très long. La cohabitation à long terme me semble problématique.
L'approche tout refaire avec Redox OS de 0 évite cet écueil mais Linux a un bel écosystème, a beaucoup (mais vraiment beaucoup) de pilotes, systèmes de fichiers, et ses sous systèmes peuvent gérer une grande variété de situations que peu de noyau savent faire, etc. Ce n'est pas pour rien je pense que l'ambition du noyau Fushia a été revue à la baisse, car incapable de rattraper le retard de Linux sur la prise en charge du matériel sans un investissement réellement massif. C'est ce qui risque de compliquer la tâche à Redox OS. Linux n'est pas irremplaçable, mais c'était bien moins ambitieux de détrôner Unix en 1990 avec un noyau neuf que de faire de même avec Linux aujourd'hui.
Cela n'est pas simple, mais si la communauté du noyau Linux est trop conservatrice, ce n'est pas impossible qu'à terme un tel concurrent puisse rivaliser sur tous les aspects à long terme avec les avantages de Rust en prime.
[^] # Re: OK, l'humain, c'est compliqué....
Posté par Renault (site web personnel) . En réponse au lien Réactions de David Airlie (Red Hat) et Asahi Lina (d'Asahi) à propos de Rust dans le noyau Linux. Évalué à 4.
Le plus difficile est forcément le début.
Il y a beaucoup de choses à mettre en place avant de pouvoir écrire le premier pilote. Il faut mettre en place les outils nécessaires pour la compilation et intégrer avec le système de build existant.
Pour tirer profit de Rust il faut définir beaucoup d'interfaces pour faire le lien entre le code C et Rust afin d'avoir un modèle cohérent entre les deux et pouvoir communiquer ensemble sans broncher.
C'est assez fastidieux et les premiers bénéfices ne sont pas très visibles au début, surtout qu'en général les premiers tests se font souvent sur des pilotes ou composants légers où le gars de l'écriture en Rust est difficile à réellement estimer.
Cela rend tout le travail de ce petit monde long, pas très agréable d'autant que l'accueil par les développeurs en place est de fait froid, cela peut créer des frictions pour le travail en C actuel (car si une structure change, le code Rust pour faire l'interface doit être adaptée).
C'est donc une situation difficile jusqu'à que la situation se stabilise et que Rust quitte l'état d'expérimentation dans le noyau Linux pour faire partie intégrante du noyau sur le long terme. C'est d'autant plus gênant que jusqu'à cette étape il y a des difficultés. LLVM ne gère pas toutes les architectures que le noyau Linux gère jusqu'à présent. Les outils de compilations du noyau dans les différentes distributions ou chaine de compilation (type Yocto ou buildroot) sont bien impactés par son introduction du moins si certains composants rendent Rust obligatoires. Et beaucoup de développeurs du noyau ne connaissent pas vraiment Rust ce qui rend la cohabitation forcément problématique pour la revue des correctifs ou pour corriger du code Rust qui dépend sur du code C qui est changé.
Je pense en effet qu'introduire Rust ne peut se faire que dans une optique de progressivement remplacer le code C existant jusqu'à qu'il disparaisse presque complètement. Mais cela sera très long. La cohabitation à long terme me semble problématique.
L'approche tout refaire avec Redox OS de 0 évite cet écueil mais Linux a un bel écosystème, a beaucoup (mais vraiment beaucoup) de pilotes, systèmes de fichiers, et ses sous systèmes peuvent gérer une grande variété de situations que peu de noyau savent faire, etc. Ce n'est pas pour rien je pense que l'ambition du noyau Fushia a été revue à la baisse, car incapable de rattraper le retard de Linux sur la prise en charge du matériel sans un investissement réellement massif. C'est ce qui risque de compliquer la tâche à Redox OS. Linux n'est pas irremplaçable, mais c'était bien moins ambitieux de détrôner Unix en 1990 avec un noyau neuf que de faire de même avec Linux aujourd'hui.
Cela n'est pas simple, mais si la communauté du noyau Linux est trop conservatrice, ce n'est pas impossible qu'à terme un tel concurrent puisse rivaliser sur tous les aspects à long terme avec les avantages de Rust en prime.