This article has been inspired by the recent controversy about the inclusion – or not – of some code written in the Rust programming language inside the Linux kernel. For some context, I should mention that the Linux kernel, like most other UNIX-like kernels, has been written mostly in a standard dialect of C. To sum up, the basics of the question is that some developers are in favor of including code in Rust in, at the very least, parts of the kernel source code. Device drivers have been mentioned. But there has been some pushback by other developers who do not agree with this move, in at least one case leading to a discussion about whether code written in Rust should even be able to access routines written in C. Linus has come in very clearly on the topic, setting out that developers responsible for parts of the kernel code who wish to write in Rust may do so, while others may prefer to stick to C. But people must be able to access each other’s code with no hindrance.
L’inspiration de cet article est la controverse récente concernant l’inclusion – ou pas – d’un peu de code écrit dans le langage de programmation Rust à l’intérieur du noyau Linux.
Pour un peu de contexte, je dois mentionner que le noyau Linux, comme la plupart des noyaux de type UNIX, est écrit principalement dans un dialecte standard de C. Bref, les bases de la question sont que certains développeurs sont favorables à l’inclusion de code en Rust dans, au moins, des parties du code source du noyau. On a mentionné des pilotes. Mais d’autres développeurs n’en veulent pas et ne sont pas d’accord, dans au moins un cas qui a engendré une discussion sur le fait que du code écrit en Rust doit quand même pouvoir accéder à des routines écrites en C. Linus s’est exprimé clairement sur le sujet, en disant que les développeurs responsables pour des parties du code de noyau qui veulent écrire en Rust peuvent le faire, tandis que d’autres préfèrent rester en C. Mais les gens doivent pouvoir accéder au code des autres personnes sans entrave.
There are arguments to be made on both sides of this matter. On the one hand, adding an additional programming language to an already complex kernel source code tree further increases complexity. There are no two ways about that. Also, being able to read and understand the complete source code will be made more complex, since now a working knowledge of both languages would be required. However, it must be said that Rust syntax is actually rather close to C, and, if anything, is slightly more readable. So this argument is actually not really valid, in my view.
Des arguments existent des deux côtés du conflit. D’une part, l’ajout d’un langage de programmation supplémentaire dans l’arbre du code source déjà complexe du noyau rendrait les choses d’autant plus complexes. C’est sans équivoque.
De plus, pouvoir lire et comprendre le code source complet deviendra encore plus complexe, puisque, maintenant, une connaissance opérationnelle des deux langages sera nécessaire. Toutefois, je dois dire que la syntaxe de Rust est en fait plutôt proche de celle de C et légèrement plus lisible. Ainsi, à mon avis, cet argument n’est pas vraiment valide.
On the other hand, Rust is presented as a much more secure programming language than C, specifically as regards memory management. It could be said that Rust has been designed to avoid the typical programming errors that plague beginners coding in C, such as assigning pointers but then not freeing the memory they point to afterwards, or inversely trying to free up too much space, or fringe effects such as modifying what a pointer points to in two code sections at the same time. This is said to be literally impossible in Rust, or, at the very least, much harder to make mistakes. The Rust compiler has very many built-in safeguards to avoid such potentially bad and hard-to-detect mishaps in a critical piece of software as is the kernel.
D’autre part, Rust est présenté comme étant un langage de programmation beaucoup plus sûr que C, particulièrement en ce qui concerne la gestion de la mémoire. On pourrait dire que Rust a été conçu pour éviter les erreurs typiques de programmation qui tourmentent des débutants qui codent en C, comme assigner des pointeurs, mais ne pas libérer la mémoire indiquée par la suite, ou, inversement, essayer de libérer trop d’espace, ou des effets périphériques tels que modifier ce qu’un pointeur indique dans deux sections de code à la fois. Il est dit que c'est littéralement impossible dans Rust ou, à tout le moins, beaucoup plus difficile de faire de telles erreurs. Le compilateur de Rust contient beaucoup de garanties innées pour éviter de tels incidents qui sont potentiellement mauvais et difficiles à détecter dans un logiciel critique comme le noyau.
From the point of view of us *buntu users, what exactly could the potential effects of including more Rust code in the Linux kernel be? These are not very many, in reality. Perhaps the kernel itself would be slightly larger, since it is unavoidable that some routines should be duplicated. We can expect some degree of increase in stability, though it must be said that the current state of affairs is not bad at all from that point of view. What will certainly be impacted is the toolkit one would need to compile a kernel. In addition to the standard GCC compiler suite, one would now need the Rust toolchain as well. In some cases, this may be something of a drawback, such as when porting the kernel for a new physical platform. Preparatory steps will now include not only making sure some version of GCC is available to cross-compile for the new architecture, but we may very well find ourselves also porting the Rust compiler first, or at least some parts of it.
De notre point de vue, les utilisateurs de *buntu, quels pourraient être exactement les effets potentiels de l’inclusion de plus de code Rust dans le noyau Linux ? Il n’y en a pas beaucoup, en fait. Il se peut que le noyau même soit légèrement plus grand, puisqu’il est inévitable que certaines routines sont dupliquées. Nous pouvons nous attendre à une augmentation de stabilité dans une certaine mesure, bien que je doive dire que l’état actuel des affaires n’est pas du tout mauvais de ce point de vue. Ce qui sera certainement impacté, c’est la boîte à outils qui sera nécessaire à la compilation d’un noyau. Outre la suite de compilation standard GCC, la chaîne de compilation de Rust sera également nécessaire. Dans certains cas, cela pourrait être un inconvénient, tel que le portage du noyau pour une plateforme physique nouvelle. Les étapes préparatoires devront inclure maintenant non seulement de s’assurer qu’une version quelconque de GCC est disponible pour faire une compilation croisée pour la nouvelle architecture, mais on pourra très bien être amené à porter d'abord le compilateur de Rust, ou, au moins, certaines parties de celui-ci.
Since the Rust compiler uses LLVM for code generation (see the “Rust Compiler Developer Guide”, available online), it may very well be that the complete Linux kernel project may find it best to slowly go from the GCC compiler to LLVM. There already seem to be projects such as Android or ChromeOS that use this latter toolchain, so it could very well be not only possible, but even relatively easy. Once more, this would probably be an issue that most users would hardly even be aware of. So, in final analysis, is all this merely but a storm in a teacup? Not really, there is more to it.
Puisque le compilateur Rust utilise LLVM pour la génération du code (voir le « Rust Compiler Developer Guide », disponible en ligne), il se pourrait que le projet complet du noyau Linux trouve qu’il vaut mieux aller lentement du compilateur GCC à LLVM. Il semblerait qu’il y ait déjà des projets tels qu’Android ou ChromeOS qui se servent de cette dernière chaîne de compilation ; ainsi, ce serait non seulement possible, mais même assez facile. À nouveau, ce serait probablement un problème que la plupart des utilisateurs ignoreraient complètement.
Ainsi, en dernière analyse, tout cela est-il simplement une tempête dans un verre d’eau ? Pas vraiment, il y a plus que cela.
For those who are not programmers, I would like to draw a parallel between the different philosophies of the C and Rust programming languages, and using a manual or an automatic transmission in a motor vehicle. People who are used to shifting their own gears by hand are usually rather good at it and may even take some pride in the fact. After some practice, they may gain finer control over their car’s drivetrain and a better feeling for the forces moving through the shafts and into the wheels, and, in general, a better comprehension of the mechanics of shifting gears. This would in general not be the case of the driver of a car who uses an automatic gear shift, and who perhaps is prepared to sacrifice some mastery of the mechanics in exchange for the convenience of just getting from one place to another with minimum fuss. In much the same way, a proficient C programmer will have gained the experience, over the years, to not make specific mistakes. For this person, the Rust compiler’s very many nanny-helping mechanisms will not be much of a practical help, and may actually constitute a hindrance for getting things done in an efficient manner. But a Rust compiler will avoid many mistakes and may actually be easier on younger programmers, empowering them to build complex pieces of software without having to previously take some hits over arcane types of bugs.
Pour ceux qui ne sont pas programmeurs, j’aimerais établir un parallèle entre les philosophies différentes des langages de programmation C et Rust et l’utilisation d’une transmission manuelle ou automatique dans un véhicule à moteur. Les gens qui ont l’habitude de changer leurs vitesses à la main le font généralement bien et peuvent même en être fiers. Après un peu de pratique, ils peuvent acquérir un contrôle plus fin sur la transmission de leur voiture et une meilleure sensation des forces transitant par l’arbre de transmission pour descendre dans les roues et, en général, une meilleure compréhension des mécanismes du changement de vitesses. Cela ne sera généralement pas le cas du conducteur d’une voiture automatique, qui est peut-être prêt à sacrifier de bonnes connaissances des mécanismes pour le confort d’aller d’un endroit à un autre avec un minimum d’agitation. De la même façon, un programmateur expérimenté de C aura augmenté son expérience pendant des années, et ne fera pas d'erreurs spécifiques. Pour cette personne, les mécanismes d’aide du compilateur Rust ne l’aideront pas beaucoup, mais, au contraire, l’empêcheront d’accomplir des choses de façon efficiente. Mais un compilateur Rust évitera beaucoup d’erreurs et sera plus commode pour les plus jeunes programmateurs, les aidant à construire des logiciels complexes sans devoir auparavant se confronter à des types ésotériques de bogues.
Is this a good thing? Perhaps so, and perhaps not. But consider: we are speaking of open-source development that is mostly done on a voluntary basis. The average age of contributors may be difficult to ascertain, but some key figures of this world are clearly not going any younger. When current leaders need to step down and hand the reins to the next generation, we will probably have to talk about programming style and whether the more hard-core C language with pointers and whatnot is really suited to the newer programmers’ style or vision of kernel programming. In that sense, Rust may very well be a suitable middle ground to build a bridge between generations. It still retains some of the quirks of C, but there is now a handrail between the walkway and the drop down into the abyss of kernel panic. Also, have you noticed how some youngsters nowadays are quite incapable of handling a manual transmission properly?
Est-ce une bonne chose ? Peut-être bien que oui, peut-être bien que non. Mais n’oubliez pas que nous parlons du développement de l’Open Source qui se fait pour la plupart sur la base du bénévolat. Il serait peut-être difficile de connaître l’age moyen des contributeurs, mais il est clair que certains personnages clés de notre monde ne deviennent pas plus jeunes. Quand les chefs actuels devront passer leur pouvoir à la prochaine génération, nous devrons probablement parler de style de programmation et si le langage C, plus caractérisé, avec des pointeurs et ainsi de suite, est vraiment ce dont les programmateurs plus jeunes ont besoin pour programmer le noyau comme ils le voudraient et dans leur style. Dans ce sens, il se peut que Rust soit un bon terrain intermédiaire pour construire un pont entre les générations. Il garde toujours certaines des bizarreries de C, mais maintenant il y a une rambarde entre le sentier et la chute dans l’abysse du « kernel panic » (plantage).
De plus, avez-vous remarqué que certains jeunes de nos jours ne savent pas du tout utiliser correctement une transmission manuelle ?