Torvalds: Rust Kernel Code Isn't Forced In Over Maintainers' Objections (kernel.org) 60
Linus Torvalds responded Thursday to kernel developer Christoph Hellwig, who had claimed Torvalds merged Rust code into the kernel even over his objections as the original C code's maintainer. Highlights from Torvalds' response:
The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL. It was literally just another user of it, in a completely separate subdirectory, that didn't change the code you maintain in _any_ way, shape, or form... Honestly, what you have been doing is basically saying "as a DMA maintainer I control what the DMA code is used for".
And that is not how *any* of this works. What's next? Saying that particular drivers can't do DMA, because you don't like that device, and as a DMA maintainer you control who can use the DMA code? That's _literally_ exactly what you are trying to do with the Rust code. You are saying that you disagree with Rust — which is fine, nobody has ever required you to write or read Rust code. But then you take that stance to mean that the Rust code cannot even use or interface to code you maintain...
You don't have to like Rust. You don't have to care about it. That's been made clear pretty much from the very beginning, that nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so. So to get back to the very core of your statement:
"The document claims no subsystem is forced to take Rust"
that is very much true. You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it...
You can't have it both ways. You can't say "I want to have nothing to do with Rust", and then in the very next sentence say "And that means that the Rust code that I will ignore cannot use the C interfaces I maintain".... So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't *have* to deal with Rust.
But that "wall of protection" basically goes both ways. If you don't want to deal with the Rust code, you get no *say* on the Rust code. Put another way: the "nobody is forced to deal with Rust" does not imply "everybody is allowed to veto any Rust code".
Torvalds also made sure to add some kind remarks, including "I respect you technically, and I like working with you."
And that is not how *any* of this works. What's next? Saying that particular drivers can't do DMA, because you don't like that device, and as a DMA maintainer you control who can use the DMA code? That's _literally_ exactly what you are trying to do with the Rust code. You are saying that you disagree with Rust — which is fine, nobody has ever required you to write or read Rust code. But then you take that stance to mean that the Rust code cannot even use or interface to code you maintain...
You don't have to like Rust. You don't have to care about it. That's been made clear pretty much from the very beginning, that nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so. So to get back to the very core of your statement:
"The document claims no subsystem is forced to take Rust"
that is very much true. You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it...
You can't have it both ways. You can't say "I want to have nothing to do with Rust", and then in the very next sentence say "And that means that the Rust code that I will ignore cannot use the C interfaces I maintain".... So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't *have* to deal with Rust.
But that "wall of protection" basically goes both ways. If you don't want to deal with the Rust code, you get no *say* on the Rust code. Put another way: the "nobody is forced to deal with Rust" does not imply "everybody is allowed to veto any Rust code".
Torvalds also made sure to add some kind remarks, including "I respect you technically, and I like working with you."
Perhaps Rust should have been kept out (Score:3, Insightful)
of the kernel code. Not because of the language itself but because it seems to me that for right or wrong its causing a whole load of grief with people working on the code. If certain people want to force Rust into the kernel for whatever reason perhaps it would be best if they just forked it like Google did and work on their own version then it can sink or swim based on its own merits.
Re: (Score:3)
I wonder how much benefit it gives. I imagine it's not negligible considering Torvald's support for it, but wouldn't code be riddled with "unsafe" blocks in Rust to get the desired kernel-level control?
Re:Perhaps Rust should have been kept out (Score:5, Insightful)
Take a look at the Linux CVE list- https://lists.openwall.net/lin... [openwall.net] . Over 80% of the bugs are from drivers, with over 300 suspected security bugs in January 2025 alone. If Rust even quash 30% of them (fair assessment since memory management in C is hard) then Rust in Linux would be considered a success.
Re: (Score:2)
On the other hand, there is this: https://cve.mitre.org/cgi-bin/... [mitre.org]
Re: (Score:2)
Let me preface this by sayinng I do not like rust. I find the language ugly, and most of its cult members highly annoying at best.
Only one bug in that list you posted was related to memory management, and the worst case scenario is memory exhaustion, and not root@pwnedbox:~#
Other bugs are logic errors that simply result in undesired behavior, rather than root@pwnedbox:~#
Re: (Score:2)
Not riddled. There would be certain sections that are unsafe that deal with direct device/memory access. Those could be separated out, and the algorithmic parts of the kernel (which is the vast majority) can use that as an API when needed. Far less of the kernel deals directly with device control than you'd think.
Re:Perhaps Rust should have been kept out (Score:5, Informative)
Quoted from Greg Kroah-Hartman [wikipedia.org]:
The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust.
Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values,
and use-after-free mistakes. 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.)
https://lkml.org/lkml/2025/2/1... [lkml.org]
Re: (Score:3)
but wouldn't code be riddled with "unsafe" blocks in Rust to get the desired kernel-level control?
And why you think code riddled with "unsafe" blocks is just going to be accepted? If I was a maintainer of any code, my first question would be why is the submitter posting a patch that has lots of "unsafe" blocks?
Re: (Score:2)
I think that if you're interfacing with hardware the "unsafe" blocks are often going to be necessary. Which, of course, eliminates much of the reason to use rust in the first place.
OTOH, I'm NOT an expert in this field. This is based of encounters with attempts to "make code safe" multiple decades ago.
Re: (Score:2)
I think that if you're interfacing with hardware the "unsafe" blocks are often going to be necessary. Which, of course, eliminates much of the reason to use rust in the first place.
But why would it be "necessary"? Is unsafe C blocks just written all the time?
OTOH, I'm NOT an expert in this field. This is based of encounters with attempts to "make code safe" multiple decades ago.
The whole point of Rust is safer code. If it isn't safer, why develop unsafe Rust code? They could stick to existing C code in that case.
Re:Perhaps Rust should have been kept out (Score:4, Informative)
Not because of the language itself but because it seems to me that for right or wrong its causing a whole load of grief with people working on the code.
By your argument, Linux should never add on anything new because it would cause a lot of grief to someone.
. If certain people want to force Rust into the kernel for whatever reason perhaps it would be best if they just forked it like Google did and work on their own version then it can sink or swim based on its own merits.
Except you like Hellwig are framing the problem in the same way. Linus decided Rust in the kernel should be supported. Zero part of the core kernel has Rust. As the founder of Linux, Linus has decided the kernel should support it for optional development. If you don't want Rust support in Linux, why don't you create a fork?
Re: (Score:1)
No, Linux should follow evolution of programming languages. I never wrote a line of code in Rust, but I can see the appeal. Being stricter, it forces programmer to apply rigor and formalism in writing the code and that code will be more secure in the long term, both later when someone tries to modify it or just by bitrot, i.e. with the risk of other changes in the codebase creating vulnerabilities in this code that were previously not possible.
There will always be resistance and changes can be postponed, bu
Re: (Score:3)
No. Fuck you for suggesting the exact same thing as Hellwig except for on a grander
Re: Perhaps Rust should have been kept out (Score:1)
I dont fucking care sonny, was just a post. Now run along to mummy, she's done your dinner.
Re: (Score:2)
Awww, did I hurt your little feewings? Or did Linus reject your println!("Hello world!"); contribution because you screwed up your syntax?
Re: Perhaps Rust should have been kept out (Score:2)
LOL :) No hurt feelings, sorry, but you did give me a good laugh. You're just another unintentionally amusing troll probably with size issues who pretends to be the big shoot from the hip tough guy online. Now go play with your fwuffy wuffy teddy bear cupcake :)
Re: (Score:2)
The fact that you keep responding strongly suggests otherwise, and very much shows that you care.
Your initial post was not just "a post." If it was, you wouldn't be so triggered by these replies.
Linus is the best babysitter ever (Score:5, Informative)
Haven't seen or heard of anyone so successful with a kindergarten this large since FDR.
Re: (Score:2)
What we NEED is some major extensions (not macro hacks) to C to allow functionality of Rust instead of failing to address big problems that led to the creation and popularity of Rust in the 1st place. That makes it into an optional security feature instead of yet another programming language with a few new ideas + a bunch of preferential decorations.
Re: (Score:3)
What we NEED is some major extensions (not macro hacks) to C to allow functionality of Rust instead of failing to address big problems that led to the creation and popularity of Rust in the 1st place.
Okay, why don't you start doing that since you seem to have the answer? How about the fact that no one seemingly has added this major functionality to C speaks to the difficulty. Remember C is not some brand new programming language that no one knows anything about. C is over 50 years old and there even a standards for C. ANSI C is on version C23 (October 2024). If you can convince someone of this need and get it passed by ANSI, go right ahead. No one is stopping you.
However in 2012, Graydon Hoare and Mozi
Re: (Score:2)
What we NEED is some major extensions (not macro hacks) to C to allow functionality of Rust
It's been done [github.com]. And done [github.com].
And you know what it looks like every time? Basically as if somebody tried to rewrite rust, only they did it half-assed because their borrow checker implementation doesn't work particularly well, or the code ends up being clunky and non-ergonomic.
That last one is actually a rarely spoken of and very underrated feature of rust, but it's something the rust development team has spent a ton of effort towards without ever really advertising it: Ergonomic code. Especially when it comes to
Re: (Score:2)
+5 you just made my day
Re: (Score:2)
That and Linus has changed over the years.
I'm going to say he matured and became more diplomatic.
Re: (Score:2)
Hmm... you mean like X vs Wayland?
So far, I understand Rust will be kept for drivers and possibly mostly new drivers (so, nowadays, mostly modules) where many bugs aren't scrutinized as well as they are if the core of the kernel. I don't think anybody is talking about rewriting the kernel in Rust yet.
Re:Some people follow fashion (Score:5, Informative)
Rust is now 13 years old. When Linus first released the Linux kernel in 1991, the C programming language was 19 years old, and Unix V7 had only been out for 12 years.
There are more than a dozen kernels written entirely in Rust [github.com]. The claim that Rust is immature is pure propaganda.
Re: (Score:2)
There are more than a dozen kernels written entirely in Rust. The claim that Rust is immature is pure propaganda.
Where are the performance comparisons?
Re: (Score:2)
The claim that Rust is immature is pure propaganda.
No. Rust is not stable. Please note that "stable" is jargon for "unchanging," a lot of casual observers and young programmers confuse it for meaning "uncrashing," which is the non-technical usage.
Rust is unstable. The argument for this is that it is less work to make changes and it hasn't been in wide use long enough to foresee exactly what changes will be needed. This is true, but it also adds technical debt to the choice of Rust, as changes in future version may require changes to your code, and there isn
Re: Up next (Score:1)
Cookies N Cream
Adding Rust is more than just security (Score:3)
Re: (Score:2)
Do we know why this is, exactly?
Are you asking why young people learn a new up and coming language that has been promised to be better than C and studied in virtually every university degree?
Young people want to program in Rust for the same reason young people 30 years ago wanted to program in C. It's trendy right now.
And goddammit if I didn't go through university where every damn course focused on Java. Though I guess there's a reason why I never became a programmer.
Re: (Score:1)
Plus if you've written anything in a higher level language, C is very tedious, because you keep having to do the same things by hand over and over again.
In the distant past there were reasonable excuses as to way: it's faster, makes better use of resources, has low level access etc. By the early 2000s after compilers git gud there were feet good reasons, but there were a lot of angry old farts with weird and misplaced opinions about c++. Today there's little reason for the yoof to listen to them, and anyway
Re: (Score:2)
Young people want to program in Rust for the same reason young people 30 years ago wanted to program in C. It's trendy right now.
I have to say, I hear the word "trendy" or maybe "novelty" or "flavor of the month" thrown around a lot. But I don't see what's "trendy" about rust. Does that just mean that the syntax is easier to understand for beginners? That there's no mile long list of deadtree books to buy off of amazon just to start with? That you can just pick up the language by doing nothing more than installing rustup and vscode? That the only book you'll ever need is always updated along with the actual language and costs nothing
Re: (Score:2)
.... or it will end up under the control of IBM, Google, Facebook and the like.
Linux is, to a large extent, under the direction of those who contribute, and the majority of the significant contributions are from those major companies (and their ilk) or the organizations those major companies fund, and they fund those people to work on things those companies customers want.
One of the things their customers want is fewer bugs and security issues. Rust is not magic, and can't fix all mistakes, but it can eliminate a large class of errors that even the existing experienced developers
People don't like change (Score:3)
I'm Running into this a work. We have YEARS of Java code and it's a Mess. Look I did Java for 20+ years. It still works, but our group is doing micro services in Kubernetes. Go (or Rust) works better since it's compiled, we don't have to create pods configured with a JDK + other Java stack things... Gradle etc .. For Micro services its easier, faster. We have other old guys that just won't let it go. On top of that the younger developers we get are hard to keep, cause they don't want to do Java.
Re: (Score:2)
Go could easily be a better choice, if only it could be documented with Doxygen. ... lets be kind and say unpleasant.
I really want to like go, but the documentation system is
Re: (Score:2)
Smart people usually come to the same conclusions.
Re: (Score:2)
That's a boss's fucking job.They never care if you are an ace Vulcan. (If they do listen carefully, bottle it, because it probably won't last long.)
That being said, fork off "Rustix" already. If devs keep loudly arguing over the same thing over and over it's unlikely to ever be settled (in a lifetime). Thus, forkit and shuddup!
Re: (Score:2)
Thus, forkit and shuddup!
Linus probably realizes that someone will likely do that if he says Rust will never be allowed anywhere in Linux. It's probably two orders of magnitude easier to port an existing project than create it from scratch, especially with emerging AI tools that could do much of the grunt work.
If such a fork were successful, he could basically lose control of his life's work. So he's doing the prudent thing by letting some of the device drivers use Rust.
Re: (Score:2)
I doubt that he's worried about that particular problem. Managing turf fights is difficult enough. It it were only about technical issues, Unix would never have faded.
Re: (Score:3)
Linus stood firm, he's the thin blue line (Score:1, Insightful)
N/t
C Was Made to Make Linux (Score:2)
Yes, any mistake made programming a kernel will either have terrible consequences if the bug is large, or cause hidden problems if the bug is small--but this is the nature of writing an
Re:C Was Made to Make Linux (Score:5, Informative)
...but I am concerned that Rust will bifurcate the knowledge required to program the kernel.
I don't think it matters nearly as much as you might think. No one can maintain the entire kernel, as it's too big for one person to hold in memory. There are already subsystems using other languages (the kernel config, for example, at least used to be written in a non-C language). There are maintainers and maintainers for the maintainers. As Linus stated, there are walls between the Rust portions and the C portions of the kernel, and never shall the two be forced to meet.
Someone maintaining the Rust code will maintain the Rust code, and someone maintaining the C code will maintain the C code, and I see absolutely nothing wrong with this. Whether a Rust maintainer will ever work on the C code will depend on whether the Rust programmer also wants to maintain C. The C code will remain C code. Whether a C programmer wants to work on the Rust code will depend on whether the C programmer also wants to maintain Rust. The Rust code will remain Rust.
Christoph is afraid of change (change can be hard, so it's understandable), and is making a mountain out of a speck of dust.
Re: (Score:2)
Re:C Was Made to Make Linux (Score:4, Interesting)
The trouble is, computers are far bigger and more complex now than when C and the UNIX kernel emerged. There was nothing anywhere near the complexity of, for argument's sake, a modern GPU driver, and there was no computer with enough memory to compiling something as complex as a modern GPU driver. C isn't good at scaling up to this level of complexity, and developers start demanding more expressive languages to help them manage the complexity.
Now I know you're thinking, "He's going to say we should be using C++ in the kernel," but I'm not. Yes, I'm a C++ developer, but I can recognise that C++ isn't a great fit for the kernel. Encapsulation, templates and automatic unwind would be great, but other parts of C++, not so much. You'd need to use some subset of C++ without exceptions, and that would mean you couldn't use the throwing new operator or anything that depends on it for propagating errors, which means a lot of the standard library is out of the question, and you need to write your constructors in an "un-C++" way. It would make "kernel C++" effectively a different language for a developer to learn anyway. The NeXTStep kernel (and by extension the XNU kernel, at least in the first few versions of Mac OS X) used a subset of C++ like this for drivers. It felt weird to use.
Is Rust a great fit for the kernel? I don't know, I don't have a huge amount of experience with it. There are some things that seem worrying. For example the way it reorders structure members means you can't organise a large structure to keep members that are accessed as a group together. It relies on shared pointers an awful lot, which means it does a lot of interlocked memory operations, and that has a significant performance cost. I don't like the lack of a formal standard or multiple implementations - that was a very real issue for Perl 5 where the documentation literally said that if the implementation and documentation disagreed, the implementation was correct.
So anyway, for better or for worse, the two language choices for kernel work are C and Rust, so developers who want a more expressive language than C are flocking to Rust. They aren't necessarily choosing Rust because it's ideal for what they're doing, they're choosing it because it's that or C, and C sucks for a lot of the things they're doing. Rust may not be ideal, but is more expressive than C and helps manage complexity.
Re: (Score:2)
There are some things that seem worrying. For example the way it reorders structure members means you can't organise a large structure to keep members that are accessed as a group together.
Annotate your struct with #![repr(c)]. One line, that's it. Really. But don't do it if you don't need to -- this disables a compiler optimization in the name of compatibility. If your struct isn't crossing a language boundary, there's no need for this.
It relies on shared pointers an awful lot, which means it does a lot of interlocked memory operations, and that has a significant performance cost.
Not sure what you mean by this. If it's pointer aliasing, which does carry a performance cost, safe rust doesn't even permit this. Unlike C++, there's no need precede everything with "const" and "strict" everywhere -- you get that implicitly everywhere in rust
Re: (Score:3)
I don't think there is much danger of that happening. Most likely almost all Rust code will be limited to drivers, and there will always be C drivers too. So anyone wanting to implement a new driver can pick C or Rust based on their preferences. And for fixing bugs, most of them are simple enough that any competent programmer can fix them in both languages.
Re: (Score:2)
I am just a bystander, but I am concerned that Rust will bifurcate the knowledge required to program the kernel.
Knowing a computer language does not give you knowledge of how to program the kernel. Understanding the details of kernel programming does that. Just like the fact that someone speaking German instead of English doesn't magically make them more logical or a better university lecturer. There's a difference between knowing the language and using it. The knowledge required to program the kernel is unchanged, you just need to speak the language, and programming languages are not hard to learn, the fundamentals
Re:C Was Made to Make Linux (Score:4, Insightful)
As a bystander, I have questions: Is it a fling with Rust--or will it replace C for programming the Linux Kernel? If it is just a fling, perhaps it would be best to keep it out and let the experiment run in a parallel fork. If it's not a fling--then is your Rust coder base large enough to replace all the C programmers? Because--do you really think that most C programmers are going to jump ship to Rust?
Rust code is not part of the main Linux kernel. It is optional for drivers to use it so support must be in Linux. As of now, Rust is being tested to see how well it works. If it accomplishes the goals that proponents have championed like reducing critical bugs, someday it might replace C. But that day is not today. What we see is a lot of resistance to any idea of Rust. In this case Linus pointed out Hellwig's objection to Rust meant he was actively preventing others from using Rust. Imagine if another maintainer said something along the lines of "RISC-V will never work, and I will do everything I can in Linux to prevent it from working even in code I don't maintain."
Re: (Score:2)
Fewer people will have what it takes to see the big picture.
A valid concern, but not really applicable because the big picture here is the interfaces, not the code itself. You only need a one-weekend level of understanding of the other language to talk with people about the interfaces and issues they might have.
And there is no need for Rust to replace anything. New stuff that is written in Rust will require a Rust maintainer, but new written in C already required somebody submitting it for inclusion to agree to also maintain it. C stuff will continue to be maintaine
Next time someone says men are not emotional (Score:2)