Linux kernel in-tree Rust support(lore.kernel.org)
lore.kernel.org
Linux kernel in-tree Rust support
https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+djd68fp7mzmBp3-wY--Uw@mail.gmail.com/T/#u
491 comments
These threads always devolve into "rust is too slow" written by developers (or enthusiasts) that have never written no_std code in production. I've written and shipped firmware for embedded devices written in rust, yes, still using cargo and external crates, and had zero issues with compile time because the nature of the dependencies in the deps tree is different and very carefully curated.
Anyway, I really just wanted to point out that from the mailing list we have Linus and Greg endorsing this experiment/effort from the Linux side and a commitment from Josh on behalf of the rust team to grow the language itself with the needs of the kernel in mind. That's quite impressive and more than I could have hoped for.
I've actually played with writing kernel code in rust - for Windows/NT, however - and it's quite weird to be able to use such high-level type constructs in code where you typically manually chases pointers and wouldn't be surprised to see statically allocated global variables used to monitor reference counts.
Anyway, I really just wanted to point out that from the mailing list we have Linus and Greg endorsing this experiment/effort from the Linux side and a commitment from Josh on behalf of the rust team to grow the language itself with the needs of the kernel in mind. That's quite impressive and more than I could have hoped for.
I've actually played with writing kernel code in rust - for Windows/NT, however - and it's quite weird to be able to use such high-level type constructs in code where you typically manually chases pointers and wouldn't be surprised to see statically allocated global variables used to monitor reference counts.
The title is not very accurate, this is a thread about a discussion on this topic which will happen at the upcoming Linux Plumbers Conference in late August.
Immunant folks wrote a blog post [1] about automating conversion of Linux kernel drivers from C to Rust by using their tool c2rust[2].
[1] https://immunant.com/blog/2020/06/kernel_modules/
[2] https://github.com/immunant/c2rust
[1] https://immunant.com/blog/2020/06/kernel_modules/
[2] https://github.com/immunant/c2rust
Pleasantly surprised by Linus response. IIRC his attitude to C++ was that it should be refused if only to keep C++ programmers out.
So this surprises me, obviously this is early discussion about a potential topic, but the general consensus seemed to be more positive than I thought.
I thought I'd remembered reading something (maybe from linus) that seemed very against having rust in the kernel, can anyone find a source for that, I searched a little and can't?
(caveat, I obviously realise that linus isn't supporting rust in the kernel, and is only saying something bounded that, if we have it, it shouldn't be completely hidden behind some config options, but it doesn't match my memory)
I thought I'd remembered reading something (maybe from linus) that seemed very against having rust in the kernel, can anyone find a source for that, I searched a little and can't?
(caveat, I obviously realise that linus isn't supporting rust in the kernel, and is only saying something bounded that, if we have it, it shouldn't be completely hidden behind some config options, but it doesn't match my memory)
Just stating something obvious since I don't see it noted here: Linus is a smart guy with this idea of not wanting it to be some niche feature that nobody enables and hence nobody cares about and sees breakage from.
I always find these email threads very hard to follow, specially on mobile.
Is there anyway to have them shown more friendly?
Is there anyway to have them shown more friendly?
6 months ago, as I hopped on the Rust train, I told a friend of mine that I'm convinced that Rust will "eat the world" like Python did[0]. These moves to see Rust enter the Linux kernel only prove to me that this pace is starting to pick up.
0. https://www.techrepublic.com/article/python-is-eating-the-wo...
0. https://www.techrepublic.com/article/python-is-eating-the-wo...
Assuming this happened and some essential drivers were written in Rust, would this effectively exclude GCC from being used to compile the full kernel?
So I don't know much about kernel development.
How many other languages apart from C are there in the kernel?
How many other languages apart from C are there in the kernel?
what does linux kernel in-tree support mean? that drivers can be written in rust or something?
Tangential question: what would be a career path for a typical product developer to become one of the programming gods who get invited to such discussions? (Even if it's technically open mailing list, you know what I mean). How many years of experience and how much formal CS education would it take to acsend to that level?
The problem I perceive with Rust as a language for Linux, is not that Rust is not an excellent language. It is that it evolves rather quickly and code may break when you switch versions.
Does rust/llvm even support all the CPU architectures Linux supports?
If not how will that work? Will some drivers be then limited to only some architectures?
If not how will that work? Will some drivers be then limited to only some architectures?
While I like Rust I still picked Modern C++(17) for my next project. All modern languages are converging these days.
Adopted C++ because of its libraries at large. Will still learn Rust on the side. For the moment, boring and verified for product especially when they're updating and remaining up to date.
Adopted C++ because of its libraries at large. Will still learn Rust on the side. For the moment, boring and verified for product especially when they're updating and remaining up to date.
To bootstrap Rustc you have to compile every single version. Say goodbye to reproducible builds. Say goodbye to civilians with cheap laptops being able to compile their kernel.
Happy to see happening!
But to get the most value out of Rust, one needs to use the Cargo ecosystem too (even for kernel code!) and that will be a much bigger political quagmire.
But to get the most value out of Rust, one needs to use the Cargo ecosystem too (even for kernel code!) and that will be a much bigger political quagmire.
My only complaint about Rust is terminology.
"Immutable variable" what an oxymoron!
That's what is known as a constant!
A variable is mutable, a constant is not. Was it that hard to understand?
"Immutable variable" what an oxymoron!
That's what is known as a constant!
A variable is mutable, a constant is not. Was it that hard to understand?
Hmm... Might be time to start looking into Rust. Is it popular in college? I think that's what made Python displace Java.
EDIT: lol. Decided to dive in a hit this almost immediately: https://docs.rust-embedded.org/book/start/io.html
EDIT: lol. Decided to dive in a hit this almost immediately: https://docs.rust-embedded.org/book/start/io.html
Hopefully this will not pass - The requirement of having GCC + LLVM + Rust installed in order to build kernel would be insane.
Now there is no legitimate reason to lock out C++.
I have a hard time seeing this happen. Rust has most of the same properties which prevent C++'s inclusion in-tree. (Look up Linus' opinions on C++ if you aren't already familiar.)
Further, as far as I can tell, Rust currently lacks mainline GCC support which I believe will be a blocker.
Further, as far as I can tell, Rust currently lacks mainline GCC support which I believe will be a blocker.
Formal leaning HN people: Does Rust just have better sales & marketing than C++? Or is it really better for safety and correctness?
* Rust is NOT a programming language with deep, well-integrated support for proof systems or state exploration e.g. TLA+.
* Rust is no Frama-C where static analysis and function contract support is far more apparent and important
* Rust is not ADA
* The previous items also arise and are quite important as a direct result of generality: to the extent Rust imposes (albeit with benefit) language design to avoid certain kinds of functional issues, those features can later become limitations as a pushy, over opinionated language. Therefore to have flexibility in designing fast code that's yet correct code one usually has to have the low-level ability of C/C++ augmented with formal tools.
I'm not seeing Rust do that. Now, I've made a couple of jokes elsewhere in HN about Rust's propensity to show up uninvited to every vaguely language issue and press its case --- ex. I was vacuuming the floor yesterday when Rust somehow got through the front door and was explaining how a Rust vacuum is so much better, or how I'd never need to vacuum again if I used Rust. But I am only half joking.
For the last year I've spent much of my time in GO after getting sick-and-tired of C++ build/language complexity for the previous 10+ years. I am somewhat aligned to others who rightly ask if speed is all that matters? (Recall the Meyers joke about Pavlov training and C/C++ programmers when it comes to speed).
Correctness counts too and if the compiler spends a little bit more I time I'd be fine with that if for distributed/parallel programming I've got good guarantees.
For those who use TLA, SPIN, Frama-C and other formal tools what's your take on this? I think designers of those kinds of formal tools will be surprised to learn some of their correctness aims were solved by Rust.
* Rust is NOT a programming language with deep, well-integrated support for proof systems or state exploration e.g. TLA+.
* Rust is no Frama-C where static analysis and function contract support is far more apparent and important
* Rust is not ADA
* The previous items also arise and are quite important as a direct result of generality: to the extent Rust imposes (albeit with benefit) language design to avoid certain kinds of functional issues, those features can later become limitations as a pushy, over opinionated language. Therefore to have flexibility in designing fast code that's yet correct code one usually has to have the low-level ability of C/C++ augmented with formal tools.
I'm not seeing Rust do that. Now, I've made a couple of jokes elsewhere in HN about Rust's propensity to show up uninvited to every vaguely language issue and press its case --- ex. I was vacuuming the floor yesterday when Rust somehow got through the front door and was explaining how a Rust vacuum is so much better, or how I'd never need to vacuum again if I used Rust. But I am only half joking.
For the last year I've spent much of my time in GO after getting sick-and-tired of C++ build/language complexity for the previous 10+ years. I am somewhat aligned to others who rightly ask if speed is all that matters? (Recall the Meyers joke about Pavlov training and C/C++ programmers when it comes to speed).
Correctness counts too and if the compiler spends a little bit more I time I'd be fine with that if for distributed/parallel programming I've got good guarantees.
For those who use TLA, SPIN, Frama-C and other formal tools what's your take on this? I think designers of those kinds of formal tools will be surprised to learn some of their correctness aims were solved by Rust.
To put this in perspective, though: increasing the number of people paid to work on the Rust compiler by 10x would only mean hiring about 25 people. Compared to the size of the projects that are starting to depend on Rust, that's a rounding error.