Torvalds: Rust Kernel Code Isn't Forced In Over Maintainers' Objections (kernel.org) 137
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:3)
On the other hand, there is this: https://cve.mitre.org/cgi-bin/... [mitre.org]
Re:Perhaps Rust should have been kept out (Score:4, Interesting)
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)
Sure, but "fixing" memory management is not actually that important. Fixing code, and more importantly, coder quality quality is. The reality is that memory issues are caused by developer incompetence (i.e. "skill issue") and that incompetence will simply cause other problems if prevented technologically. (Which is a stretch, many drivers will have to go "unsafe" to even work...). The reason why people mistakenly think fixing memory issues is important is because all the different ways to screw that up get
Re: (Score:2)
Why don't people use assemble? It is awesome and fast!! bug and other issues are code quality issues, devs should make better assemble code!!
If the language is harder to control, code quality and bugs are easier to show up. The more small details you have to control, the harder it is and more resources is required from devs to keep tracking those details. That is why people use C instead of assemble!
Now rust helps in the same way, it still gives lot control and performance, but makes it easier for devs and
Re: (Score:2)
also read the comment https://linux.slashdot.org/com... [slashdot.org] below
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: (Score:2)
Rust and all the other magic solutions claim that they can do the missing testing simply by forcing the programmers to use certain patterns of logic. If you can't say the word "blue" then you can't say any
Re: (Score:2)
C is not unsafe.
Give me a break. As an expert C developer, much better than you for sure, I can assure you that C is a minefield full of minefields that get nastier as your project scales up.
Re: (Score:2)
I think that if you're interfacing with hardware the "unsafe" blocks are often going to be necessary.
Sure, but they can are will be minimized and isolated. When interfacing with hardware, you need to write to registers and you need to write to shared memory buffers. In both cases, what you'd do is write a small unsafe block that does the unsafe thing, and very carefully validate the code and all of the assumptions it makes, and document exactly why it's actually safe. Then everywhere else in the driver, you just call those carefully-vetted unsafe routines.
You should read some of the unsafe kernel and
Re: (Score:2)
I wonder how much benefit it gives.
Massive. Generics, just to pick a killer one. We do kind of hack up generics in C but it is super fragile, tedious to write and nigh-on unreadable.
Re:Perhaps Rust should have been kept out (Score:5, 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:2, Insightful)
No. Fuck you for suggesting the exact same thing as Hellwig except for on a grander
Re: (Score:2)
C++
lol. Linus would burn it to the ground before he allowed a line of C++ in the kernel.
Did you really formulate that entire response out of your ass? You did pretty good, I must say.
Re: (Score:2)
lol. Linus would burn it to the ground before he allowed a line of C++ in the kernel.
Yeah, that's probably true.... but the beauty of Linux is that if you or I disagree with Linus's position, we can fork the Linux codebase directly into our own NewC++OSThatDefinitelyIsn'tLinux project today and go to town, adding C++ into the kernel however we want.
Granted, that would be building our own circle of hell around us, but anybody who thinks it's a good idea is more than welcome to give it a try and find out for sure one way or the other.
Re: (Score:2)
I've hated C++ passionately since I was forced to learn it in college... but reading Linus' opinion of it makes me blush.
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.
Re: Perhaps Rust should have been kept out (Score:2)
Remember who responded first cupcake, wasnt me. Now go work off all your incel frustration and anger the only way you know how...
Re: (Score:2)
Actually, it was you. Linus previously made a decision that Rust code would be included in the kernel, and just now overrode Hellwig to put this Rust code in the kernel, and you responded to that decision as reported here with some masturbatory fantasy that perhaps those decisions made by people far more qualified than you should have been made differently according your personal take on "a whole load of grief" by a vocal minority of whiners.
Re: (Score:2)
"Actually, it was you"
No, cupcake, YOU responded to MY initial post. You didn't have to but you decided to try and sound intelligent which sadly for you failed but that seems to be par for the course for you looking at your past posts.
"You're obviously projecting, which means your replies are unintentionally pretty revealing, I'd say."
You say a lot, but rarely anything of import and psychology 101 really isn't your forte. Maybe I'll tell my kids they were an immaculate conception to see the surprise :)
Anywa
Re: (Score:2)
Or did Linus reject your println!("Hello world!");
Seems unlikely that this particular individual would submit code in Rust at all, being they're against it. ;)
Beyond that, Rust in-kernel strives to follow the C nomenclature for outputting text to places where a user can retrieve them. That means no println()
I see small hints that you're standing on a soapbox that you don't actually have any knowledge of in the slightest. Again, I must say, you're doing a (mostly) good job at arguing from your ass, here.
Re: (Score:2)
Are you serious right now?
Do you think you have stdout in the kernel?
Re: (Score:2)
In the kernel, we use printk(). We wrap that with pr_err, pr_warn, etc.
In Rust, they do the same.
As I said- you're clearly talking out of your ass- but really, I do salute you. Someone who hadn't spent 30 years developing software in and around the linux kernel probably wouldn't realize it.
Re: (Score:2)
That was literally the joke, son. Hence the "rejected because you screwed up your syntax" bit.
Re: (Score:2)
As I said- good attempt, but you fell flat.
A submission using println! wouldn't be rejected because of syntax issues- it would be rejected because that particular Rust macro wouldn't do anything in the kernel, whatsoever.
I pointed out that the kernel/rust folks use the C nomenclature, and then you post a link to rustlang, saying "do tell" (lol)
You're talking about of your ass. Just stop it. It looks terrible.
Re: (Score:2)
Yes, it actually was. Also, I'm not particularly concerned with how you think that it looks.
Re: (Score:2)
Also, you're clearly interested in programming and kernel development. You should pursue that- learn why posting a link to rustlang was laughably stupid.
Then learn what the word syntax fucking means
Re: (Score:2)
Still stubbornly standing just a step away.
I'm not having the pedantic syntax versus semantic error fight with you tonight. You've already pointed out how it violates the rules of the language for kernel programming, but again you just can't bring yourself to follow through.
Re: (Score:2)
Using println!() isn't a syntax error. It's not really an error at all. It's an absurdity. You didn't know that- which is completely understandable.
Someone who has never worked in the kernel *wouldn't* know that.
Hell, 99.9999% of anyone who has ever touched Rust or C, and thus had to compile *without* their stdlib (std:: in rust) wouldn't even know that.
Being println! is actually a macro in std:: that turns, ultimately, into a write()- that would ultimately fail to link, but it wou
Re: (Score:2)
Mea culpa
Re: (Score:2)
Again, not having that debate with you tonight. Go back to the 80s and argue with the CS faculty then. Then get a patent for your time travel invention so that the effort is actually worth it.
Because someone else is way too confident in the completeness of their knowledge, as well as the supposedly esoteric idea that t
Re: (Score:2)
Tell us again about the C++ in the kernel, please.
You know what would happen on the LKML if you called a linking error a syntax error? lol.
There's no pedantry involved- they're different things that are entirely unrelated.
Seriously dude, slink away and go spend the night in a hole, lol.
Re: (Score:2)
Posing as what, exactly? I never claimed to be a kernel programmer, or even a Rust programmer. I took some basic CS, C, and C++ courses way back in the pre-eternal September age in connection with an engineering degree. Yet it never took a genius to know that application programming functions like printf() don't work in kernel programming. Well, I take that back. Some master kernel programmer claims that it does.
Obviously there was never any error at all, an
Re: (Score:2)
Posing as what, exactly? I never claimed to be a kernel programmer, or even a Rust programmer.
The why, in the name of fuck, are you talking the shit you talk?
Telling some dude "fuck you", because they have an equally uninformed opinion about something he knows nothing about?
Hellwig had a technical reason for his argument.
You can argue it was, or was not a good one, but you cannot say it didn't exist. Ultimately- I don't even think you fucking understand it though!
So why would you tell someone "fuck you" for a technical argument you don't understand?
I personally support Rust in the kernel, but
Re: (Score:2)
Re: (Score:2)
However you wish to characterize that reason, yes. To quote some self-important interloper, "You can argue it was, or was not a good one, but you cannot say it didn't exist."
That was not a technical reason. There is not a "technical" barrier to the use of Rust. It was a political re
Re: (Score:2)
This perfectly illustrates the pig-wrestling problem. You're arguing that *people not behaving as expected* in accordance with a policy designed to prevent blocking is a "technical" problem. There's nothing technical about it. The prior version works, the intended version works, and something else is perm
Re: (Score:2)
Feel free to fork the kernel and remove rust. Torvalds seems fine with rust being there, so doesn't seem like that's going happen with his "fork".
Re: (Score:2)
Ultimately though, if you support Rust in Kernel, I wouldn't get too comfortable.
There are still big barriers to its full first-class adoption- particularly in its limited set of supported architectures.
This means that for the time, it's still relegated to the outskirts in certain device drivers unlikely to exist on other architectures.
I've been writing low-level code for a few decades. All C, of course (how long will I be able to say that, I wonder?)
I've got a bit of wor
Re: (Score:2)
its causing a whole load of grief with people working on the code
It isn't. Never mind that Christoph is a squeaky wheel. Great developer but not exactly progressive. What is causing a whole load of grief for kernel developers is lack of a modern systems programming language. Few would argue against generics for example, the status quo being an ugly soup of hand-rolled C conventions and unreadable macros. The thing is, that modern systems programming language was expected to be c++ until Rust came along. Both are up to the task, but Linus hates c++ and isn't too offended
Re: (Score:2)
Rust is not just stricter, it is also more expressive than C. Completely different ballpark of expressiveness.
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: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. 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)
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)
Both Circle and Carbon are more related to C++ than C. And Circle looks really good, honestly, for those coming from a C++ background. I wouldn't be surprised to see Circle merge slowly into C++ over the next few years as the language is revised. Circle implements nearly all of the Rust concepts in a way that works with C++. It's not safe by default, but uses an opt-in mechanism, so it allows you to slowly replace unsafe code in an existing code base. Will be interesting to see how it works out.
Zig migh
Re: (Score:2)
I wouldn't be surprised to see Circle merge slowly into C++ over the next few years as the language is revised.
I wouldn't be surprised if it's a commercial project in disguise. Not only is the compiler closed source, but it also does things that I really think shouldn't be built into a general purpose programming language, like CUDA integration.
Anyways, it seems the C++ working group doesn't even want to do any of that, and they're still debating what the word "safety" means, which is honestly kind of pathetic [thecodedmessage.com].
I do see why they don't want to though because in order to do what circle does, it actually has to make fun
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)
It is a part of the job, which he has managed brilliantly. Special bonus that he doesn't appear to have become a snowflake with an enormous ego and a chronic butt-hurt.
Adding Rust is more than just security (Score:3)
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)
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: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)
That is a long post about a complete misinterpretation of the word trendy. It doesn't imply flavour of the month, more like flavour of the decade. It's undeniable that Rust use and popularity is growing along with how much it is taught is growing.
Trendy means "fashionable and up to date", and there's no denying it fits that definition. That doesn't mean we're talking about a discipline where the trends change every month. And it literally has nothing to do with anything you listed, except for one thing.
But
Re: (Score:2)
That is a long post about a complete misinterpretation of the word trendy.
I don't think so. Are you sure you understand what trendy means?
Trendy means "fashionable and up to date", and there's no denying it fits that definition.
Bell bottoms are trendy, but they're hardly what I'd call up to date.
the mile long list of dead tree books published on a topic doesn't make something trendy, quite the opposite, it makes it mature, older, and very likely no longer trendy
You mean like the piles and piles vinyl records out there? It was popular around the same time as C even though it's older. Oh wait...but vinyl is also trendy. So then why isn't C trendy?
If it's about being new, then golang is newer than rust, so why not golang?
Trends are defined by interest. How many C books are being written today?
My hunch is that if you did a survey on programming books published in the last year, you'd probably find more of kot
Re: (Score:2)
"C is very tedious, because you keep having to do the same things by hand over and over again."
Hm. libraries exist? It is true that C does not come with much out of the box, but you certainly do have to do things by hand over and over again.
Re: (Score:2)
Yeah libraries exist, but so the small details like allocating and freeing resources in the right order even in case of error conditions has to be done by hand.
C Was Made to Make Linux (Score:3)
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 operating system. Is it not?
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?
In the midst of all of this, and because this is not the first thread that has come through Slashdot in the last 6 months on the subject--is Rust offering promise? Or will it drive a stressful wedge between the developers? In the meantime, perhaps it's best to keep Linux lean, efficient, and commented.
I am using Linux more and more on my machines. Thank you all for your effort!
[I have been working on a communication protocol for micro-controllers such as the Teensy/Arduino. Lately, I am trying to make a minimal model for device drivers. While using Arduino's and Teensy's you are always making device drivers, but it's another thing to try to make them generic, and make the rest work in a HAL sense, and that is where the challenge begins. So, while I have never worked on the Linux Kernel, from even as far back as I am--I can appreciate what everyone is doing. So, thank you again.]
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:3)
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)
at least for the linux apple M1 GPU driver, it is already tested, it allowed a very fast driver development that works very well. :)
and no, no memory related security problems found yet
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)
Re: (Score:2)
in a company that i worked, a problem between 2 women ended that all (around 6) but 1 (a developer, so less emotional) quit almost at same time 2 months after. The boss manage to revert one of those (the secretary), because both sides in the issue had no people anymore, if she stayed, everything was still fine
So just having 2-3 people leave the kernel development is far from the "usual" emotional reaction
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:3)
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:Some people follow fashion (Score:4, Informative)
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't a system for compiling one section of code under a specific version. In C, we have stable versions. So my module can use C11, and if somebody wants to include it in something that's using C17 they'll be fine. In Rust there is no guarantee of that. Another defense offered is, "in practice they avoid changes that will break things." That's good, but still different than a mature system with stable versions. Also they point out they don't have the management resources to do all that; in C it is done by corporate developers acting in consortium. Also true. They're probably making the best decision for Rust, but for C developers it will be less stability than what they're used to.
I think everybody agrees that eventually Rust will be stabilized, and the C developers will agree it is "mature."
Re: (Score:2)
If that is your definition then C isn't stable either. In fact it's most recent revision (commonly referred to as a change) was only published a few months ago: ISO/IEC 9899:2024 - Information technology — Programming languages — C
Re: (Score:3)
If that is your definition then C isn't stable either. In fact it's most recent revision (commonly referred to as a change) was only published a few months ago: ISO/IEC 9899:2024 - Information technology — Programming languages — C
C standards are typically forward compatible. This means code written in an old standard should still compile and work as before with a compiler using the new standard.
Rust doesn't have "standards" but it has "editions". Rust strives to provide compatibility within the same edition.
Furthermore, the kernel relies on some unstable Rust features [rust-for-linux.com]. Rust explicitly warns that those features may be changed in a breaking way. Work to stabilize those features is underway.
Re: (Score:2)
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.
You're not even wrong. However, the difference between these two things is that the number of features in C was minuscule compared to Rust. More importantly, new features were not regularly added to C on the whims of a small group of developers.
There are more than a dozen kernels written entirely in Rust [github.com].
Kinda. Most of the listed kernels were abandoned more than six years ago which means they are all based on different versions of the Rust language. None of them seem to adhere to a particular Rust language standard which means they are unlikely to compile using the l
Re: (Score:2)
I know a lot of things that are 13 years old and aren't even remotely mature.
Re: Some people follow fashion (Score:3)
Age is a number. How about Perl, a 37 year old man-child. It's "mature", stable even, but you know, it's Perl ... collecting SSI and living off pizza. It will die of a heart attack in a few years and nobody will go to that funeral. It just won't be in your repo one day.
Some things should stay in mom's basement playing D&D with BASIC. So are we being desperate or does Rust make sense. I don't think it even brushes its teeth, just sayin. We can't do better, or this is us giving up?
Re: (Score:2)
So C/unix had 12+ years as the undisputed de facto standard of operating systems
Not remotely. There were many other programming languages and operating systems.
C and Unix were mostly restricted to academic environments; industry use was fairly small. Even Bell Labs ran most of their real work on mainframes running MVS. In fact, early versions of Unix, up until around 1980, were called "Research Unix", because the OS was really only used in research environments. It wasn't until System 7 in 1983 that it really began to get much industry adoption, and wasn't until the mid to late 80s
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)
Re: (Score:2)
L.inux I.s N.ot U.niX.
Re: (Score:2)
don't mix things:
Gnu is not Unix
Linux is unix inspired
Re: (Score:3)
Re: (Score:2)
Not sure what I have to do with anything. But a snarky joke about someone quitting over something you disagree with that caused lots of debate and upset several people has a specific name. We call that trolling. You'd know that if you weren't Slashdot's biggest idiot.