Sinds Linus Torvalds inbegrepen Rust in Linux Kernel versie 6.1, de taal wint geleidelijk aan terrein en steeds meer ontwikkelaars sluiten zich aan bij deze beweging.
Echter enkele ontwikkelaars van de linux-kernel Ze benadrukken dat vooruitgang steeds meer werk en uitdagingen zal betekenen, aangezien zij in hun opmerkingen impliceren dat er een patstelling kan ontstaan.
Het is de moeite waard om te verduidelijken dat we niet vermelden dat de implementatie op een dood spoor zit, maar eerder gezien de opmerkingen van verschillende ontwikkelaars en zoals we al vermeldden, in de huidige staat de noodzaak begint te ontstaan om het werktempo te verlagen, of dat is tenminste wat het volgende artikel ons suggereert LWN.net.
En enkele weken geleden kwam ik dit artikel tegen dat ingaat op de huidige staat van het gebruik van Rust in Linux en analyseert of het experiment met deze programmeertaal succesvol is geweest.
Er wordt vermeld dat er al enkele jaren Roest is een onderwerp dat niet meer wordt besproken op de "Kernel Onderhouders Summit" en die van 2023 vormden geen uitzondering, aangezien sinds de officiële implementatie van Rust als tweede programmeertaal in Linux, Miguel Ojeda, Rust-for-Linux-ontwikkelaar, benadrukte de groeiende belangstelling voor het gebruik van Rust voor kernelontwikkeling tijdens de sessie gewijd aan dit onderwerp.
Miguel Ojeda vermeldt dat het project Rust-voor-Linux heeft het afgelopen jaar een grote impuls gekend, sinds een fulltime ingenieur en een student-ontwikkelaar zich hebben aangesloten en verschillende bedrijven zich hebben aangesloten bij het ondersteunen van het werk. Daarnaast wordt er gewerkt aan de integratie van de Coccinelle-tool met de Rust-code. Niet alles is echter rooskleurig, aangezien een van de huidige uitdagingen het werven van meer reviewers is voor de code die wordt ontwikkeld.
In het artikelen vermeldt dat de problemen merkbaar beginnen te worden in de gereedschapsketen, sindsdien voortgang van de compiler GCC-gebaseerde Rust, bekend als gccrs, is vertraagd. Aan de andere kant laat de GCC-codegenerator voor rustc veelbelovende vooruitgang zien en is deze samengevoegd met de compiler, waardoor Rust-ondersteuning kan worden uitgebreid naar architecturen die niet compatibel zijn met LLVM.
Binnen de kernel, Er wordt vooruitgang geboekt in verschillende subsystemen, dat is het geval bij de Rust-implementatie van Android-bindmiddel die vergelijkbare prestaties heeft aangetoond als de C-implementatie, met een minimale hoeveelheid onveilige code. Daarnaast wordt er gewerkt aan het koppelen van bestandssystemen met als doel alleen-lezen ondersteuning in Rust te bereiken, met de visie om een volledig veilig bestandssysteem in Rust te implementeren.
Dave Airlie, de beheerder van het DRM (grafische) subsysteem, zei dat als hij zijn zin krijgt, er in de komende paar releases een samengevoegde Rust DRM-driver zal zijn. Christoph Hellwig antwoordde dat Airlie bereid was "ieders leven tot een hel te maken", zodat ze met haar favoriete speeltje kon spelen. Hellwig zei dat het samenvoegen van Rust anderen zou dwingen om te gaan met een tweede taal, nieuwe toolchains en ‘wrappers met vreemde semantiek’. Dan Williams zei dat de huidige situatie "is hoe succes eruit ziet" en dat de kernelgemeenschap al toegewijd was aan Rust.
Hoewel er onder beheerders een groeiende belangstelling is voor het adopteren van Rust, er ontstaan uitdagingen, sinds er over gedebatteerd is kernelreferentiestuurprogramma's nodig hebben die in Rust zijn geschreven om te laten zien hoe controllers in deze taal kunnen worden geschreven. De duplicatie van functionaliteit tussen stuurprogramma's in Rust en C heeft echter wantrouwen onder beheerders gewekt.
De discussie over de opname van Rust heeft verschillende kanten opgegaan: Welnu, sommige beheerders pleiten voor het samenvoegen van standalone Rust-drivers, zoals de binder-driver, om hun levensvatbaarheid aan te tonen, terwijl aan de andere kant van de medaille anderen Ze uiten hun zorgen over de complexiteit van het onderhouden van een kernel met twee programmeertalen.
Airlie vervolgde met te zeggen dat veel van het werk van Rust momenteel een beetje een kip-en-ei-probleem is. Abstracties kunnen pas worden samengevoegd als er een gebruiker voor is, maar code die deze abstracties nodig heeft, wordt geblokkeerd in afwachting dat de code meerdere subsystemen bereikt. Als gevolg hiervan hebben ontwikkelaars die aan Rust werken grote hoeveelheden patches bij zich die ze nodig hebben om hun code te laten werken. Om dat obstakel te doorbreken is het nodig dat sommige abstracties zonder directe gebruikers toegang krijgen.
Ondanks de uitdagingen, kernelgemeenschap erkent het potentieel van Rust om de codebeveiliging en stabiliteit te verbeteren. Er bestaat de mogelijkheid om in de toekomst breder gebruikte stuurprogramma's in Rust samen te voegen, zodra de zorgen over patchbaarheid en onderhoudbaarheid zijn opgelost.
Ojeda was het ermee eens dat deze kwestie de voortgang heeft vertraagd, maar zei dat hij heeft geprobeerd de beheerders niet onder druk te zetten om de code snel samen te voegen. In het geval van netwerken moesten de Rust-ontwikkelaars ironisch genoeg de netwerkmensen vragen het samenvoegen van de Rust-code te vertragen.
Ten slotte is het vermeldenswaard dat de weg naar wijdverbreide adoptie van Rust op Linux uitdagingen met zich meebrengt; de interesse en vooruitgang op dit gebied is duidelijk. Er wordt verwacht dat Rust in de loop van de tijd een belangrijke rol zal spelen bij het verbeteren van Linux.
bron: https://lwn.net/