Greg Kroah-Hartman Supports Rust in the Kernel (phoronix.com) 43
An anonymous Slashdot reader shared this report from Phoronix:
Linux's second-in-command Greg Kroah-Hartman has also been a big proponent of Rust kernel code. He's crafted another Linux kernel mailing list post [Wednesdsay] outlining the benefits of Rust and encouraging new kernel code/drivers to be in Rust rather than C. Greg KH makes the case that the majority of the kernel bugs are due to "stupid little corner cases in C that are totally gone in Rust."
"As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years... and who sees EVERY kernel CVE issued, I think I can speak on this topic," Kroah-Hartman began. Here's some excerpts from his remarks. Citing corner cases like overwrites of memory, error path cleanups, use-after-free mistakes and forgetting to check error values, Kroah-Hartman says he's "all for... making these types of problems impossible to hit." That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)... [F]or new code / drivers, writing them in Rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this...? Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn't we want that...?
Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together.
Kroah-Hartman emphasized later that "a huge majority of the stupid things we do in C just don't happen in the same code implemented in Rust (i.e. memory leaks, error path cleanups, return value checking, etc.) "
The complete thread contains over 140 messages — including Linus Torvalds' observation that " #pragma is complete garbage and should never be used."
"As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years... and who sees EVERY kernel CVE issued, I think I can speak on this topic," Kroah-Hartman began. Here's some excerpts from his remarks. Citing corner cases like overwrites of memory, error path cleanups, use-after-free mistakes and forgetting to check error values, Kroah-Hartman says he's "all for... making these types of problems impossible to hit." That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)... [F]or new code / drivers, writing them in Rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this...? Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn't we want that...?
Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together.
Kroah-Hartman emphasized later that "a huge majority of the stupid things we do in C just don't happen in the same code implemented in Rust (i.e. memory leaks, error path cleanups, return value checking, etc.) "
The complete thread contains over 140 messages — including Linus Torvalds' observation that " #pragma is complete garbage and should never be used."
Some kernel developers need to get out of the 90's (Score:2, Interesting)
Greg is absolutely right. Go be a dinosaur somewhere else.
Re:Some kernel developers need to get out of the 9 (Score:4, Insightful)
Re: (Score:3)
It isn't about that.
It's about the possibility of permittng new code to be written in Rust and it just working with the C code.
Nothing New to Linux Devlopment (Score:4, Insightful)
Rust seems to attract a completely insufferable variety of programmer that is very difficult to deal with.
This is nothing new to Linux development. Are you one of the young'ins that don't even know about RMS?
Re: (Score:3, Insightful)
This controversy is not about a technical problem. For whatever reason, Rust seems to attract a completely insufferable variety of programmer that is very difficult to deal with. This is not going to be a smooth transition for a community-developed project of this size.
Your comment isn’t a technical critique—it’s a tired, personal attack that says more about your inability to engage with new ideas than it does about any shortcomings in Rust. Instead of resorting to cheap insults about “insufferable programmers,” why not focus on the actual merits and challenges of integrating Rust into kernel development? Rust brings tangible improvements in memory safety and concurrency that can only benefit a project as critical as the Linux kernel. Dismiss
Re: (Score:2, Insightful)
Rust seems to attract a completely insufferable variety of programmer that is very difficult to deal with
That's weird. It seems the last few "insufferable" programmers were the ones on the C side complaining they don't want rust in the kernel for bullshit reasons.
Re: (Score:1)
"Rust seems to attract a completely insufferable variety of programmer that is very difficult to deal with." ...and none of the members of that variety are actually programming in Rust.
Re: (Score:2)
For whatever reason, Rust seems to attract a completely insufferable variety of programmer that is very difficult to deal with.
Greg KH is an insufferable variety of programmer that is very difficult to deal with? That will be news to basically anyone who has ever dealt with him.
Re: (Score:2)
Actually, Rust seems to attract a particular variety of technically clueless but loudmouthed trolls such as yourself.
Re: (Score:3)
One of the strongest temptations... (Score:4, Insightful)
...among programmers is to rip it out and start over. I've done this many times, often achieving success
Problem is that old, crufty code works. It may be imperfect and ugly, but it works and has stood the test of time
Ripping it out and starting over is always harder than it appears, often a lot harder
It may fix some old bugs but it often introduces new ones and loses old functionality
Re:One of the strongest temptations... (Score:4, Informative)
They are griping about adding a new ABI system that would allow new code to be written in Rust and it just working with the C code.
C coders are scared that as more and more new code and modules are written in Rust that they will have to be forced to write in a new language, and they're also scared that Rust magic (their words) will do incorrect things and crash every Linux system, open up boxes to hackers, etc.
Re:One of the strongest temptations... (Score:4, Insightful)
...among programmers is to rip it out and start over. I've done this many times, often achieving success
Problem is that old, crufty code works. It may be imperfect and ugly, but it works and has stood the test of time
Ripping it out and starting over is always harder than it appears, often a lot harder
It may fix some old bugs but it often introduces new ones and loses old functionality
This is not ripping anything out, though. This is allowing simultaneous development in both C and Rust, in order to evaluate the benefits of Rust over C in a real-world project. And, based on the progress so far, both Linus and Greg K-H are seeing benefits, or at the very least, wish for the evaluation to continue. It's a bit hard to argue against the people who are arguably doing the largest amount of work on the kernel, and see all the areas that are or could be affected by it.
And yes, in the future there may be incremental migration of functionality into Rust code vs C code. It's certainly not going to be soon, and I seriously doubt that it will be rushed. From everything I have seen, the only way it will happen is from the outside in. Code on the periphery will be implemented in Rust, talking to a C/Rust interface to core C code. Slowly, as C clients of the core C code are replaced with equivalent Rust code, that core C code can be migrated to Rust.
Re: (Score:2, Interesting)
Which requires both C and Rust developers to work together, simultaneously. There's some kind of political element with Rust developers that make this functionally incompatible.
It was just last week we had a story about a Rust developer rage-quite on LKML from an issue regarding a police force in a country this developer doesn't even live in. Totally unrelated to kernel development and a massive distraction.
Re: (Score:2)
The developer in this case maintained the noveau drivers. Implemented in C. Likewise, the other developer who quit, main contributions in C. Both developers said that they have been thinking about it for a while, both noted a number of issues.
This "Rust is all political" stuff just doesn't hold water. If you go onto the Rust language forums, you will see a very helpful environment which is prepared to give people detailed technical explanations. It is one of the kinder and nicer corners of the internet. Eve
Re: (Score:2)
And yes, in the future there may be incremental migration of functionality into Rust code vs C code.
I'd say incremental migration is where we are now. Drivers are being rewritten in Rust. I expect it will stay in drivers only for a while, though it will probably include some storage and memory-related "drivers" that are very generic and needed by basically every platform.
Re: (Score:2)
Problem is that old, crufty code works.
Leaving aside the fact that no one is ripping or replacing anything, your general complaint here is worth digging into? Define "works".
Do you mean it executes? What if it doesn't tomorrow? Cruft means there's extra complexity and effort which goes into maintaining code in what is objectively an ever changing world.
Do you mean it is bug free? That's the core of the rust debate here. C has loads of edge cases creating bugs that may go undetected for years, the move to memory safe languages in this sense means
Re: (Score:2)
Ripping it out and starting over is always harder than it appears, often a lot harder It may fix some old bugs but it often introduces new ones and loses old functionality.
The current situation is Linux supports Rust drivers. The Linux kernel itself does not have Rust code. So "rippling it out and starting over" does not accurately reflect what is happening. Some existing drivers might be converting to Rust. Some new drivers may start with Rust and not C.
Does it have to be Rust? (Score:3)
Been hearing very good things about Zig from people who are expert C coders
Re: (Score:2)
Work like this, especially on open source projects, usually gets done by the people interested and motivated enough to do it. Is someone pushing for the same kind of kernel support and integration for Zig? (And does Zig provide as many safety guarantees as Rust?)
Re: (Score:3)
Zig has a different take on memory safety than Rust. Zig has many memory allocation strategies and it strictly enforces memory bounds. It has optionals and slices, and it's strict about not letting you shoot yourself in the foot. What puts Zig ahead is that its C FFI is a first-class concern, so no need for a Zig-specific ABI. It’s also significantly faster than Rust, and it has cross-compilation out of the box. If the move to Rust is for performance, then it's the wrong choice. Zig is 20-50% faster.
Re: (Score:2)
From what I've read rust is zero overhead and should produce the same fast machine code as c. I can believe zig is just as fast as rust and c but I have a hard time believing rust is 20-50% slower than c or zig. What is the basis for this claim?
Please (Score:4, Funny)
Can we have some python too? It's magical.
Re: Please (Score:2)
#pragma Has Its Place (Score:2)
Re: (Score:2)
GCC is right to give the warning: the C standard [open-std.org] says "the value of a pointer becomes indeterminate when the object it points to reaches the end of its lifetime." You might expect that free(p) doesn't modify p itself, and on your platform it might not, but the standard doesn't guarantee that.
Is it Kroah or Hartman (Score:1)
Greg can't even pick a last name. He shouldn't be picking languages for the kernel.
Re: (Score:3)
This question came from someone who daren't even pick any name for themselves.
Language counts! (Score:4, Interesting)
Programming languages that prevent these mistakes, detect them at compile-time, and/or generate well-defined runtime behavior (exceptions) have been around for a long time. (Ada 1983 is a good example, but by no means the only one. A lot of the Ada requirements and designs went into preventing or detecting these kinds of mistakes.) I've mentioned before the Bell Labs Technical Journal papers on 5ESS and the errors and mitigation strategies. These typical/chronic errors have been known for a long time: "An Empirical Study of Software Faults Preventable at a Personal Level in a Very Large Software Development Environment", Bell Labs Technical Journal Summer 1997 and " Software Fault Prevention Approach in Coding and Root Cause Analysis", Bell Labs Technical Journal April-June 1998. But they never considered -using a better programming language- (where "better" is by preventing problems through language design, or by detecting problems through compile-time or run-time checking.) Rust is yet another chance to break out from the tyranny of C/C++ and all the problems those languages facilitate. Sure, the expert programmer can produce fault-free C or C++. It takes a lot more than understanding just the language semantics; there's a lot of experience and "do it this way, don't do it that way" that programmers need to learn, usually the hard way.
But as a profession, I don't think we learn from our mistakes, in large part because we often won't admit the mistakes in the first place.
Rust is Linux Suicide (Score:1)
Rust was promoted as a C-like language, which it is not. See for your own eyes. It's interesting that the 1970s Basic statement "Let" makes a reappearance. https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
Prove Rust is a problem-free process by forking Linux to a Rust-Only fork, convert it to Rust, and then A/B it.
Yep, nothing like A/B performance testing.
My bet is: Rust Kernel will require ~4x memory space (assuming same features / modules). Result in more page swapping between memory and cache. And it will bog down far worse than C Kernel when active processes exceeds 3x processor nodes.
Re: (Score:2)
Prove Rust is a problem-free process by forking Linux to a Rust-Only fork, convert it to Rust, and then A/B it.
No one has said ever said Rust would provide a "problem-free process". No one. The design of Rust appears to solve some problems that comes with C. Currently Linux is testing whether Rust provides any benefits by allowing drivers to be written in Rust.
Rust was promoted as a C-like language, which it is not. See for your own eyes.
From your own link: the only "C-like" reference is from this The Register article [theregister.com] by Liam Proven who is a journalist and not part of the Rust foundation. So who is "promoting" that again?
Agree ... BUT (Score:1)
Re: (Score:2)
"AI-driven lint..." Huh. Can you be specific about a product, its capabilities, and its limitations? Or is this just the projection of expectations to justify an existing decision?
Me, I strongly favor solutions that PREVENT errors, rather than depending on outside tools or even testing to DETECT them. (And that started with using a debugger. For me, having to resort to a debugger was an admission that "I didn't know what the code was doing." But I guess that's just me.)
Every significant system I worke
Re: (Score:2)
The thing that gets me with this discussion is that switching to Rust (or any other language) to address the problems that arise when using C fails to address the question of why those problems exist when using C.
That is to say: the problem isn't in the language, because the language can be used properly - that is, the language doesn't "give rise" to the issues, it merely permits them to exist.
So the question is - what insufficient mental models or processes exist that cause people to use C in a way that re
Re: (Score:2)
So the question is - what insufficient mental models or processes exist that cause people to use C in a way that results in hazards?
See the first of the two BLTJ papers I referenced.
Rust in Linux is a Publicity Stunt (Score:1)
Linus's post is the final word after the gripes (Score:2)
TLDR:
C maintainers have no say in clients for their interfaces - if want to have a say in rust or any other client of their interface then be a part of that project too
Rust is in perpetual beta (Score:2)
I actually like the idea of Rust, I always thought that we really need a modern low level C replacement, something like what Ada tried to be just not shit and based on RAII principles, and Rust is pretty much that. But it has no place in the kernel. The problem is that even though Rust was made by Mozilla, it feels more like a Google product, it's a programming language that is in perpetual beta. I remember the outcry when Python 3 broke backwards compatibility, and how it took 15 years to get everybody to