Rust kernel policy(rust-for-linux.com)
rust-for-linux.com
Rust kernel policy
https://rust-for-linux.com/rust-kernel-policy
126 comments
> They don't say what their policy is regarding building the C parts with GCC and the Rust parts with the LLVM toolchain (including the Clang parts that bindgen uses).
My understanding is this concern was broached very early in the Rust for Linux project and Greg Kroah Hartman explicitly signed off on "building the C parts with GCC and the Rust parts with the LLVM toolchain". See: https://news.ycombinator.com/item?id=24335831 and https://lwn.net/Articles/829858/
> And the policies around unstable Rust features (at least they are acknowledged as a problem):
I am amazed at what short memories many have. I remember when clang couldn't build the kernel. I remember when GCC required many special extensions to the C language to even compile the kernel. I think GCC may still require some of these and clang/LLVM may require emulation of the same.
Now, Rust gets the surprise news they may be included in the kernel and they have worked diligently to stabilize certain unstable features. Can you imagine what kind of rudder movement something similar would take to turn the C/C++ committees/tankers? Obviously, language "stability" isn't the issue you make it out to be, because, for decades, the Linux kernel required GCC extensions.
My understanding is this concern was broached very early in the Rust for Linux project and Greg Kroah Hartman explicitly signed off on "building the C parts with GCC and the Rust parts with the LLVM toolchain". See: https://news.ycombinator.com/item?id=24335831 and https://lwn.net/Articles/829858/
> And the policies around unstable Rust features (at least they are acknowledged as a problem):
I am amazed at what short memories many have. I remember when clang couldn't build the kernel. I remember when GCC required many special extensions to the C language to even compile the kernel. I think GCC may still require some of these and clang/LLVM may require emulation of the same.
Now, Rust gets the surprise news they may be included in the kernel and they have worked diligently to stabilize certain unstable features. Can you imagine what kind of rudder movement something similar would take to turn the C/C++ committees/tankers? Obviously, language "stability" isn't the issue you make it out to be, because, for decades, the Linux kernel required GCC extensions.
IMO you're comparing apples and oranges. The GNU C extensions are 'stable' when using GCC, they're just not part of the regular C language, plenty of them are still in wide use in the kernel. Unstable Rust features in comparison are explicitly in a state where they could be changed/broken or removed in any later release.
You're not wrong, but at this point, there's close communication between the Linux folks are the Rust team, and the Rust team has committed to stabilizing things that the Linux team needs. There is basically no chance that suddenly one of the core things they need is going to disappear. They've already gone through the list and checked that it's all stuff that is eventually going to land.
> Unstable Rust features in comparison are explicitly in a state where they could be changed/broken or removed in any later release.
I'm not sure there is as much in that distinction as you hope for 2 reasons: 1) what is the actual stability guarantee of GCC extensions? 2) what is the cash value of your distinction to the point I was making?
Re: 1, do you not believe GCC has and would modify or remove an extension which conflicts with C standard behavior? I know of instances where GCC C++ definitely deprecated an extension after it was implemented according to the standard.
Re: 2, my actual point was it's fine, even good, that that that Rust takes time. And Rust deserves that time, especially if C features made their way into the kernel via GCC C extensions. If I were a company concerned about writing a Rust kernel driver or not -- I'd be way more concerned about the vicissitudes of more wild ass kernel maintainers, Linus, and the GCC maintainers, than whether Rust is going to stabilize any necessary items on the kernel team's list.
So, IMHO, yes, there may be some difference between GCC's extension stability guarantee and Rust's unstable (duh), depending on what you want, and how you want to look at it. But at 10,000 feet, this is a mostly lawyerly, but, trivial point.
I'm not sure there is as much in that distinction as you hope for 2 reasons: 1) what is the actual stability guarantee of GCC extensions? 2) what is the cash value of your distinction to the point I was making?
Re: 1, do you not believe GCC has and would modify or remove an extension which conflicts with C standard behavior? I know of instances where GCC C++ definitely deprecated an extension after it was implemented according to the standard.
Re: 2, my actual point was it's fine, even good, that that that Rust takes time. And Rust deserves that time, especially if C features made their way into the kernel via GCC C extensions. If I were a company concerned about writing a Rust kernel driver or not -- I'd be way more concerned about the vicissitudes of more wild ass kernel maintainers, Linus, and the GCC maintainers, than whether Rust is going to stabilize any necessary items on the kernel team's list.
So, IMHO, yes, there may be some difference between GCC's extension stability guarantee and Rust's unstable (duh), depending on what you want, and how you want to look at it. But at 10,000 feet, this is a mostly lawyerly, but, trivial point.
The Rust for Linux politics mess should be laid squarely at Linus' feet. He's the BDFL. He approved adding Rust to Linux, and he massively failed at communicating what that even meant. If he wants Rust in the kernel, he needs to kick some maintainers in the ass and get everyone aligned.
To play (BDFL's) advocate - Linux is an -enornous- project. It's not physically possible for any effort to be unilaterally directed. Linus does not personally maintain the whole thing, it's just not possible. So he has maintainers under him who are in charge of the subsystems - the implication being that he trusts their judgment and technical expertise. There's no other way the system could work, really.
Linus's position, as far as I've heard and ascertained, is that introducing any language into the kernel is going to require case-by-case and subsystem-by-subsystem analyses. He's not going to reject the language wholesale, but at the same time it's impossible for him to wholesale mandate its adoption. "Kicking maintainers in the ass" sounds great but nothing is ever that simple.
Linus's position, as far as I've heard and ascertained, is that introducing any language into the kernel is going to require case-by-case and subsystem-by-subsystem analyses. He's not going to reject the language wholesale, but at the same time it's impossible for him to wholesale mandate its adoption. "Kicking maintainers in the ass" sounds great but nothing is ever that simple.
I think this is an important point. People believe "dictator" means "complete control" when instead "dictator" mean "authority to make any decision." The difference is exactly what you say, that you still have to rely on the hierarchical structure and trust that your "underlings" are making the right decisions. Complete control doesn't scale very well and even a small project or team has many moving parts and the only way to have full control is to be involved in every part. With scale, rapidly comes the necessity for trust. There's only so much time in a day, and only so much can be done in an hour. Damned physics, always getting in the way.
Why do you assume he either wants it or doesn't want it?
The only way I ever interpreted his actions so far is he's willing to allow those who want to try.
And I see nothing unreasonable and no failure in that. It is a hashing out process, in process.
The only way I ever interpreted his actions so far is he's willing to allow those who want to try.
And I see nothing unreasonable and no failure in that. It is a hashing out process, in process.
"If he wants" != "he wants"
"He approved" != "He wants"
"He approved" != "He wants"
Either he failed at communicating, or he does not care. Reading the recent thread/flamewar on R4L and DRM I wonder if he was somewhat pressured to accept Rust but does not actually care. If you were the leader of a project and explicitly authorized a sub-project, would you tolerate a maintainer undermining it?
FWIW, there are plenty of backchannels through which discussions about this stuff can be had that aren't the public mailing list. My limited understanding is that those discussions have in fact taken place and the R4L people aren't concerned about things working out eventually.
However, I do wish he would say something publicly, so that the internet peanut gallery doesn't fill the void with negativity. It doesn't exactly help attract more interest in the project.
However, I do wish he would say something publicly, so that the internet peanut gallery doesn't fill the void with negativity. It doesn't exactly help attract more interest in the project.
And if he doesn't want it in the kernel?
I don't know enough to agree or disagree with the person you're replying to. But I assume the logic would be that if Linus doesn't approve then he should have shut the discussion down long ago or at least do it now without half measures
> then he should have shut the discussion down long ago
It's interesting that people expect Linus to simultaneously chill out and be more inclusive while at the same time acting like a dictator over the entirety of the project.
In any case, perhaps it's worthwhile to remember where it started, and what the attitudes were at the time [1]. It was an experiment. Experiments sometimes fail or reveal themselves to not lead anywhere useful. The choices were to let that experiment happen on the actual kernel or force the rust people to fork some version of the kernel and instantly be left behind.
It clearly wasn't an easy choice and I can only imagine the uproar from the rust community if he then did what you suggest today. So, that leaves us with the question, what if he's decided it's no longer worth it? What then should we do with a mostly failed kernel experiment?
[1]: https://www.zdnet.com/article/linus-torvalds-on-where-rust-w...
It's interesting that people expect Linus to simultaneously chill out and be more inclusive while at the same time acting like a dictator over the entirety of the project.
In any case, perhaps it's worthwhile to remember where it started, and what the attitudes were at the time [1]. It was an experiment. Experiments sometimes fail or reveal themselves to not lead anywhere useful. The choices were to let that experiment happen on the actual kernel or force the rust people to fork some version of the kernel and instantly be left behind.
It clearly wasn't an easy choice and I can only imagine the uproar from the rust community if he then did what you suggest today. So, that leaves us with the question, what if he's decided it's no longer worth it? What then should we do with a mostly failed kernel experiment?
[1]: https://www.zdnet.com/article/linus-torvalds-on-where-rust-w...
> It's interesting that people expect Linus to simultaneously chill out and be more inclusive while at the same time acting like a dictator over the entirety of the project.
It's not particularly interesting that different people have different expectations on different issues
It's not particularly interesting that different people have different expectations on different issues
It's interesting that you moved the goalposts to an entirely different point. I'm clearly talking about the overall "community," which whether you care about it or not, has been used as a point to successfully force Linus' hand before.
In other words, there are clearly politics involved, so perhaps that should be taken into consideration before making a blithe point about a complex human organizational issue?
In other words, there are clearly politics involved, so perhaps that should be taken into consideration before making a blithe point about a complex human organizational issue?
You can be decisive and inclusive without being a prick who is personally targeting developers and publicly demeaning. Linus was like that. No sane developer wants that. A true inclusive environment also requires leaders to tell rowdy maintainers calling people "cancer" to know their place and watch their tone.
It is not really a good experiment in technical qualification nor in developer collaboration, if the leadership lets individuals to constantly blockade work, isn't it?
It is not really a good experiment in technical qualification nor in developer collaboration, if the leadership lets individuals to constantly blockade work, isn't it?
> personally targeting developers
How else would you target them? You can disagree over tone and scope but this is an open source project with an open contribution model.
> publicly demeaning. Linus was like that. No sane developer wants that.
Show me someone who hasn't been turned to this behavior over frustration. In isolation you can always find this from a leader what you should be concerned with is context and persistence. While it was occasionally over the top the majority of the time he was perfectly "sane."
> A true inclusive environment also requires leaders to tell rowdy maintainers calling people "cancer" to know their place and watch their tone.
This is open source. What exactly is "their place?" How much time should one dedicate to policing tone? Isn't that personally targeting people but in a different direction?
Which is part of my point here. Previously we just developed and ignored Linus' hot head behavior. This push for a vaguely defined "truly" inclusive community is what I feel led Linus into the mistake of allowing Rust into core.
> if the leadership lets individuals to constantly blockade work
What if the work just isn't very good or is counterproductive to the project as a whole? What if there is no consensus on this point? How much time should one dedicate to building consensus?
How else would you target them? You can disagree over tone and scope but this is an open source project with an open contribution model.
> publicly demeaning. Linus was like that. No sane developer wants that.
Show me someone who hasn't been turned to this behavior over frustration. In isolation you can always find this from a leader what you should be concerned with is context and persistence. While it was occasionally over the top the majority of the time he was perfectly "sane."
> A true inclusive environment also requires leaders to tell rowdy maintainers calling people "cancer" to know their place and watch their tone.
This is open source. What exactly is "their place?" How much time should one dedicate to policing tone? Isn't that personally targeting people but in a different direction?
Which is part of my point here. Previously we just developed and ignored Linus' hot head behavior. This push for a vaguely defined "truly" inclusive community is what I feel led Linus into the mistake of allowing Rust into core.
> if the leadership lets individuals to constantly blockade work
What if the work just isn't very good or is counterproductive to the project as a whole? What if there is no consensus on this point? How much time should one dedicate to building consensus?
archive.ph/rESxe
>Thinking of literally starting a Linux maintainer hall of shame. Not for public consumption, but to help new kernel contributors know what to expect. >Every experienced kernel submitter has this in their head, maybe it should be finally written down.
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
>If shaming on social media does not work, then tell me what does, because I'm out of ideas.
Hector Martin went way beyond being a "prick". And Linus Torvalds told him to stop it.
Have you considered that the problem may be the people that are making "hall of shame" lists of people and doing social media brigading?
Worsening matters, Steve Klabnik (major Rust community figure, has run @rustlang, primary author of the Rust Programming Language Book, former Rust Core member, and moderator of r/rust), have been busy here and on reddit making excuses for Hector Martin. What kind of community is the Rust community?
>Thinking of literally starting a Linux maintainer hall of shame. Not for public consumption, but to help new kernel contributors know what to expect. >Every experienced kernel submitter has this in their head, maybe it should be finally written down.
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
>If shaming on social media does not work, then tell me what does, because I'm out of ideas.
Hector Martin went way beyond being a "prick". And Linus Torvalds told him to stop it.
Have you considered that the problem may be the people that are making "hall of shame" lists of people and doing social media brigading?
Worsening matters, Steve Klabnik (major Rust community figure, has run @rustlang, primary author of the Rust Programming Language Book, former Rust Core member, and moderator of r/rust), have been busy here and on reddit making excuses for Hector Martin. What kind of community is the Rust community?
I have never moderated /r/rust.
I haven’t been involved with the Rust Project for years, I speak only for myself.
I said that I feel for Hector, he’s clearly hurting, and that I hope he feels better. I’ve said I don’t want to pass judgement on if what he did is right or wrong, because I’m trying to stick to facts here. I’ve said that I don’t think what he did was particularly effective.
That’s not making excuses. Hector’s actions aren’t the main point of this story. It’s not even his patch!
I haven’t been involved with the Rust Project for years, I speak only for myself.
I said that I feel for Hector, he’s clearly hurting, and that I hope he feels better. I’ve said I don’t want to pass judgement on if what he did is right or wrong, because I’m trying to stick to facts here. I’ve said that I don’t think what he did was particularly effective.
That’s not making excuses. Hector’s actions aren’t the main point of this story. It’s not even his patch!
>rowdy maintainers calling people "cancer"
Where was this done? In the recent mailing list, the maintainer never called people cancer, he said
https://lore.kernel.org/lkml/[email protected]/
>And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
Not referring to people. And many developers would agree that a multilanguage codebase can easily end up becoming a nightmare and pure cancer to maintain, whether or not Rust is one of those languages.
Another C project has not had good experiences with all interop attempts, pulling the plug on interop with one Rust library, while keeping support for two other Rust libraries.
https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/
>Before this step, we supported three different backends backed up by libraries written in rust. Now we are down to two: rustls (for TLS) and quiche (for QUIC and HTTP/3). Both of them are still marked experimental. >These two backends use better internal APIs in curl and are hooked into libcurl in a cleaner way that makes them easier to support and less of burden to maintain over time.
Where was this done? In the recent mailing list, the maintainer never called people cancer, he said
https://lore.kernel.org/lkml/[email protected]/
>And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
Not referring to people. And many developers would agree that a multilanguage codebase can easily end up becoming a nightmare and pure cancer to maintain, whether or not Rust is one of those languages.
Another C project has not had good experiences with all interop attempts, pulling the plug on interop with one Rust library, while keeping support for two other Rust libraries.
https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/
>Before this step, we supported three different backends backed up by libraries written in rust. Now we are down to two: rustls (for TLS) and quiche (for QUIC and HTTP/3). Both of them are still marked experimental. >These two backends use better internal APIs in curl and are hooked into libcurl in a cleaner way that makes them easier to support and less of burden to maintain over time.
He needs to say so before wasting everyone's time
I remember seeing an interview where Linus said that at one time, he rejected a contribution and felt bad because he wasn't clear enough in that he didn't wanted that.
He said he now tries to be very clear about what he doesn't want. So I guess he is ok with how things are going, otherwise, we would be likely to see another of his famous rants.
He said he now tries to be very clear about what he doesn't want. So I guess he is ok with how things are going, otherwise, we would be likely to see another of his famous rants.
Exactly. The recent DRM issue was about who's time would be wasted. Rust is either happening, and they are wasting time by not having proper bindings, or it is not, and all the drivers written were a waste of time. In either case, the discussions around it are already a waste of time.
fork, runix? (/s?)
The page uses "our" and "we" a bunch of times, but doesn't say who this "we" is. The implication from the "Contact" page seems to be that this is some "Rust for Linux" group that may or may not be well defined.
Which is fine, but then the document also doesn't cite most of the things it states, and isn't always clear on what's established fact/standard and what's this group's opinion. For eg.
> Should maintainers treat Rust code up to the same standards?
> Ideally, and eventually, yes. However, when they are starting out, not necessarily.
Sections like this have no indicator for whether this is opinion they are stating, an argument they're presenting, or an already-decided kernel policy that they're citing.
---
> On the costs side, [...] most Rust language features we used were stabilized
The fact that this has to be specified - and still qualified with "most" - is a big part of the problem with this.
Which is fine, but then the document also doesn't cite most of the things it states, and isn't always clear on what's established fact/standard and what's this group's opinion. For eg.
> Should maintainers treat Rust code up to the same standards?
> Ideally, and eventually, yes. However, when they are starting out, not necessarily.
Sections like this have no indicator for whether this is opinion they are stating, an argument they're presenting, or an already-decided kernel policy that they're citing.
---
> On the costs side, [...] most Rust language features we used were stabilized
The fact that this has to be specified - and still qualified with "most" - is a big part of the problem with this.
> The implication from the "Contact" page seems to be that this is some "Rust for Linux" group that may or may not be well defined.
It says:
> For other matters, please feel free to contact the maintainers via email.
Which links to https://docs.kernel.org/process/maintainers.html#rust which has a list of people.
There is also https://github.com/Rust-for-Linux/linux/blob/rust-next/MAINT... which is the in-tree documentation of who maintainers are.
> The fact that this has to be specified - and still qualified with "most" - is a big part of the problem with this.
For a very long time, linux wouldn't even compile with clang, becuase they use gcc extensions. These are effectively the same idea as nightly features. The kernel has never used standard C. Nowadays clang has enough support and keeps it going.
I agree with you that I personally would much prefer that they were on 100% stable Rust, but the Linux folks in general are way more fine with depending on specific versions for the build.
It says:
> For other matters, please feel free to contact the maintainers via email.
Which links to https://docs.kernel.org/process/maintainers.html#rust which has a list of people.
There is also https://github.com/Rust-for-Linux/linux/blob/rust-next/MAINT... which is the in-tree documentation of who maintainers are.
> The fact that this has to be specified - and still qualified with "most" - is a big part of the problem with this.
For a very long time, linux wouldn't even compile with clang, becuase they use gcc extensions. These are effectively the same idea as nightly features. The kernel has never used standard C. Nowadays clang has enough support and keeps it going.
I agree with you that I personally would much prefer that they were on 100% stable Rust, but the Linux folks in general are way more fine with depending on specific versions for the build.
I'm an outsider, only submitted one tiny patch years ago, but it seems like this Rust for Linux initiative will end badly if it's not stopped. You have so many people involved in work on this open source OS written in C and they will be pushed to accepting foreign code. Rust, as a very complex and opinionated language, is not an easy choice to accept for C developers. If the push continues, maybe we will see the existing maintainers leaving?
Are you aware that RfL is not outsider Rust enthusiasts pushing on the kernel, but rather existing Linux kernel developers wanting to use Rust?
Internal or external, it doesn't change much. Either Rust usage remains very isolated, or Rust takes Linux over and who doesn't want to deal with Rust should leave. Even the policy acknowledges, that the rust team being responsible for fixing broken rust builds is only temporary.
Is the goal to make a good kernel or to keep C developers happy?
I don't see rust taking over C in kernel ever.
re: broken rust builds
You should think very very hard on when it can break and how it effects C side of things.
I don't see rust taking over C in kernel ever.
re: broken rust builds
You should think very very hard on when it can break and how it effects C side of things.
Rust was specifically designed to integrate well into a C codebase; and Rust for Linux was specifically for drivers - not to replace all of Linux's internals.
The two things that putting Rust in Linux actually requires of existing C maintainers is:
- They have to not get in the way of Rust bindings
- They have to document critical pre- and post-conditions of their code that impact memory safety
That last one is a problem - not one that Rust caused, but a problem that's been in Linux nonetheless. This is the thing that all the BSDs hate on Linux for. Typically, the approach to handling big breaking changes with Linux kernel objects is "make it compile, then change all the things that crash until they stop crashing". This means there isn't any documentation to write safe bindings for any Linux kernel function, since it could, say, rely on you calling three other functions in a specific order that just so happens to match the one major driver that uses that subsystem[0]. For Rust bindings to make sense and actually provide value, the subsystem maintainers need to provide documentation that they usually don't bother with.
The first one on the list is the reason why Hector Martin ragequit his maintainer position and decided upstreaming Asahi drivers isn't worth doing. There's a few subsystem maintainers that internally decided "I don't care what Linus thinks, fuck Rust". One of them happens to be the maintainer for the DMA subsystem, which happens to be... fairly critical to writing any non-toy driver.
The problem is specifically that there isn't a push for Rust. Linus is uncharacteristically fence-sitting here, to the point where people are writing Rust drivers that can't be upstreamed because his own maintainers are blocking them. Having the kernel support two languages is fine, but it requires Linus actually put his foot down and either say "stop treating the Rust people like Nvidia and let them write safe bindings to kernel internals," or, "we're not going to do Rust at all because of X, Y, or Z."
[0] I am told amdgpu is like this.
The two things that putting Rust in Linux actually requires of existing C maintainers is:
- They have to not get in the way of Rust bindings
- They have to document critical pre- and post-conditions of their code that impact memory safety
That last one is a problem - not one that Rust caused, but a problem that's been in Linux nonetheless. This is the thing that all the BSDs hate on Linux for. Typically, the approach to handling big breaking changes with Linux kernel objects is "make it compile, then change all the things that crash until they stop crashing". This means there isn't any documentation to write safe bindings for any Linux kernel function, since it could, say, rely on you calling three other functions in a specific order that just so happens to match the one major driver that uses that subsystem[0]. For Rust bindings to make sense and actually provide value, the subsystem maintainers need to provide documentation that they usually don't bother with.
The first one on the list is the reason why Hector Martin ragequit his maintainer position and decided upstreaming Asahi drivers isn't worth doing. There's a few subsystem maintainers that internally decided "I don't care what Linus thinks, fuck Rust". One of them happens to be the maintainer for the DMA subsystem, which happens to be... fairly critical to writing any non-toy driver.
The problem is specifically that there isn't a push for Rust. Linus is uncharacteristically fence-sitting here, to the point where people are writing Rust drivers that can't be upstreamed because his own maintainers are blocking them. Having the kernel support two languages is fine, but it requires Linus actually put his foot down and either say "stop treating the Rust people like Nvidia and let them write safe bindings to kernel internals," or, "we're not going to do Rust at all because of X, Y, or Z."
[0] I am told amdgpu is like this.
There were also a lot of times mentioned that current maintainers are getting old. Rust people might, with time, take over... being younger and all.
> Rust, as a very complex and opinionated language, is not an easy choice to accept for C developers. If the push continues, maybe we will see the existing maintainers leaving?
What are you talking about? I'm yet to work at a business where developers aren't proficient in 2 or more programming languages. Why do you presume that experts in the field would be blocked by a limitation that does not apply to the vast majority of professional software developers?
What are you talking about? I'm yet to work at a business where developers aren't proficient in 2 or more programming languages. Why do you presume that experts in the field would be blocked by a limitation that does not apply to the vast majority of professional software developers?
I have work on such companies unless you count TypeScript and JavaScript as two languages.
Comment you're replying to is about some kernel developers not wanting to learn/write/use rust.
Comment you're replying to is about some kernel developers not wanting to learn/write/use rust.
Every other engineering organization on the planet seems to do just fine with a polyglot codebase. Do you really think kernel maintainers are dumber than the average Google engineer?
We now have https://github.com/FractalFir/rustc_codegen_clr#c-support . So we can keep all our Rust files out-of-tree and just submit C code like everyone else.
I can't image what reviewing C code like that would look like? Rust is a complex piece of technology, is the transpiled C code 'clean' enough to be able to review it?
It certainly isn't. Getting even C code written by human with best effort for addressing standards and conventions accepted is challenging enough.
This violates the GPL.
It doesn't, because C code is clearly "the preferred form for modification" by C kernel devs that, by their own admission, are quite unwilling to deal with the perceived complexity of a multi-language code base. (Or even to learn any other programming language, for that matter.)
and eventually create this totally new language full of certainty and more...
> maybe we will see the existing maintainers leaving
That is probably true.
The reasons for Rust are compelling. And the uncountable value of the Linux kernel justifies a lot of pain.
That is probably true.
The reasons for Rust are compelling. And the uncountable value of the Linux kernel justifies a lot of pain.
Seems like a good tool for ensuring everyone is aligned.
Nit: The policy document seems inconsistent in its authoritative tone. In some sections, it hand-waves and punts to an external resource. For example: "Yes, there are key kernel maintainers who support Rust in the kernel. [Check out this PDF of keynote slides and figure it out yourself]."
Nit: The policy document seems inconsistent in its authoritative tone. In some sections, it hand-waves and punts to an external resource. For example: "Yes, there are key kernel maintainers who support Rust in the kernel. [Check out this PDF of keynote slides and figure it out yourself]."
Would YOU want to be named (without permission) in a document like this as being responsible for something in a high-visibility project like the kernel just because you contributed some code, or gave a talk at a conference?
Anyway, some slides at a conference are not the authoritative source for who works on Rust in the Linux kernel, something this is:
grep -i rust MAINTAINERS
Anyway, some slides at a conference are not the authoritative source for who works on Rust in the Linux kernel, something this is:
grep -i rust MAINTAINERS
The question of who has the authority over the policies regarding the integration of Rust code into the kernel seems like a different question than who is maintaining Rust code.
Yeah. This answer is weak. If they are really supportive, they need to put down their names.
I think the way it was handled is pretty reasonable considering it's a public facing statement. Putting your name down on an authoritative statement is an important commitment internally, but a name put down for any reason on a public statement is a magnet for a firehose of questions, controversy, and potentially harrassment.
I feel like Rust just isn’t stable or mature enough as a language for moving Linux towards it to make sense.
Currently feels like you need a PhD in programming languages to use it effectively. Feels like Haskell in many ways.
Currently feels like you need a PhD in programming languages to use it effectively. Feels like Haskell in many ways.
With all due respect I question how much experience you actually have with Rust. It's nowhere close to being as difficult a language as you describe.
Rust got popular in part because it made systems programming easier, simpler and more fool-proof than the existing alternatives (C, C++) for those coming from languages like Python, Ruby and Java. As someone whose primary experience is in Python, I never found Rust abnormally difficult to pick up, whereas Haskell is (and remains) entirely alien to me. Sure, lifetimes can get messy, but it's much easier to have the compiler hit me on the head when I'm doing something dumb than to spend 2 days figuring out how to use Valgrind and the other half-dozen different static analyzers. I don't need to devote 100% of my mental effort to be able to write reliable code that's not going to blow up later in subtle ways.
Rust got popular in part because it made systems programming easier, simpler and more fool-proof than the existing alternatives (C, C++) for those coming from languages like Python, Ruby and Java. As someone whose primary experience is in Python, I never found Rust abnormally difficult to pick up, whereas Haskell is (and remains) entirely alien to me. Sure, lifetimes can get messy, but it's much easier to have the compiler hit me on the head when I'm doing something dumb than to spend 2 days figuring out how to use Valgrind and the other half-dozen different static analyzers. I don't need to devote 100% of my mental effort to be able to write reliable code that's not going to blow up later in subtle ways.
I feel crazy when I read comments like that about Rust. C is much, much harder than Rust. C is absolutely crazy difficult. Fairly simple to learn, but incredibly hard to actually write correctly. Rust is much, much easier. The learning curve isn't that hard. One week and you can be fairly productive with it.
Kernel programming is probably one area you don’t need to optimize for newbie programmers to jump in like the web
I'm not sure lowering the barrier to contribute Linux kernel code is a great argument for C. It sounds like contributing code that doesn't segfault often still requires a PhD.
> Currently feels like you need a PhD in programming languages to use it effectively.
I've learned it because it was easier than C++ or even C. Yes you can learn C quickly, but you need much longer time than for rust to use it properly.
Also I do not have PhD not even CS degree and it was not hard. You should try it.
I've learned it because it was easier than C++ or even C. Yes you can learn C quickly, but you need much longer time than for rust to use it properly.
Also I do not have PhD not even CS degree and it was not hard. You should try it.
Rust and Haskell are completely different languages so I don't really agree here. Haskell doesn't have the features (lifetimes, ownership) that make Rust "hard" and Rust lets you have mutable states and procedural code.
Rust is also quite stable and mature by now, I'm not sure what example or reason you're using to say otherwise.
Rust is also quite stable and mature by now, I'm not sure what example or reason you're using to say otherwise.
Rust and Haskell are difficult for completely different reasons. Rust is difficult for roughly the same reasons C++ is difficult.
I must protest - putting any language on par with C++ level of difficulty is unfair to C++. (Let's exclude malbolge and its relatives for a second)
I agree that rust is much less difficult than C++. But the things that are difficult about Rust are also difficult about C++… just less difficult, because the compiler helps you with them.
This answer seems like a big spin:
> Is Rust for Linux driven by the "Rust community"?
> No, the people involved around Rust for Linux come from different backgrounds and organizations. Some are kernel maintainers, some are Rust experts. Some are hobbyists, some are employees at large corporations
> Particularly, it is not an effort driven by the Rust Project nor the Rust Foundation. In fact, Rust for Linux was founded by a Linux kernel maintainer as a hobby, it is not an effort driven by the Rust Project nor the Rust Foundation. In fact, Rust for Linux was founded by a Linux kernel maintainer as a hobby
The Rust Project says R4L is a “flagship” goal: https://rust-lang.github.io/rust-project-goals/2024h2/goals.... I recall Josh Triplett saying R4L was a big priority for Rust this year; he pledged his support.
Also, didn’t the author of this updated doc (Miguel Ojeda[1]) resign from R4L? I’m not sure what his role is here.
Edit: [1] see https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ...
> Is Rust for Linux driven by the "Rust community"?
> No, the people involved around Rust for Linux come from different backgrounds and organizations. Some are kernel maintainers, some are Rust experts. Some are hobbyists, some are employees at large corporations
> Particularly, it is not an effort driven by the Rust Project nor the Rust Foundation. In fact, Rust for Linux was founded by a Linux kernel maintainer as a hobby, it is not an effort driven by the Rust Project nor the Rust Foundation. In fact, Rust for Linux was founded by a Linux kernel maintainer as a hobby
The Rust Project says R4L is a “flagship” goal: https://rust-lang.github.io/rust-project-goals/2024h2/goals.... I recall Josh Triplett saying R4L was a big priority for Rust this year; he pledged his support.
Also, didn’t the author of this updated doc (Miguel Ojeda[1]) resign from R4L? I’m not sure what his role is here.
Edit: [1] see https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ...
> The Rust Project says R4L is a “flagship” goal
Rust's 2024H2 and 2025H1 flagship goals are about getting Rust for Linux into stable Rust, implementing features we need and so on. We really appreciate being a flagship goal of theirs! We collaborate regularly, and some members are part of both projects, and so on and so forth.
But that does not mean one is driven by the other, just like GCC and Clang do not drive the Linux kernel because they introduced features to build it. They support us, which is different.
> Also, didn’t the author of this updated doc (Miguel Ojeda[1]) resign from R4L? I’m not sure what his role is here.
I wrote the document, but I never resigned since I started the project -- you are probably referring to Wedson. I have seen articles that confused both of us in the past, so that is not a surprise, though I wouldn't mind to have Wedson's mind around from time to time :)
The FOSDEM 2025 keynote has some details about the history of the project. There is an LWN article about it: https://lwn.net/Articles/1007921/
I hope that clarifies.
Rust's 2024H2 and 2025H1 flagship goals are about getting Rust for Linux into stable Rust, implementing features we need and so on. We really appreciate being a flagship goal of theirs! We collaborate regularly, and some members are part of both projects, and so on and so forth.
But that does not mean one is driven by the other, just like GCC and Clang do not drive the Linux kernel because they introduced features to build it. They support us, which is different.
> Also, didn’t the author of this updated doc (Miguel Ojeda[1]) resign from R4L? I’m not sure what his role is here.
I wrote the document, but I never resigned since I started the project -- you are probably referring to Wedson. I have seen articles that confused both of us in the past, so that is not a surprise, though I wouldn't mind to have Wedson's mind around from time to time :)
The FOSDEM 2025 keynote has some details about the history of the project. There is an LWN article about it: https://lwn.net/Articles/1007921/
I hope that clarifies.
> Wait a second, that’s not what this page says: https://rust-lang.github.io/rust-project-goals/2024h2/goals....
I don't understand what you're saying - is your point that having Goals means that this can no longer be considered a hobby? Lots of people have hobbies where they have goals for a sense of direction and satisfaction. (Not to mention that the page doesn't say it is a hobby, just that it was started as one.)
> Also, didn’t the author resign from this effort before? Or was that departure not as dramatic as I recall.
Who do you mean by "the author" here? This seems to be a group effort by a "Rust for Linux" group, not a single individual.
I don't understand what you're saying - is your point that having Goals means that this can no longer be considered a hobby? Lots of people have hobbies where they have goals for a sense of direction and satisfaction. (Not to mention that the page doesn't say it is a hobby, just that it was started as one.)
> Also, didn’t the author resign from this effort before? Or was that departure not as dramatic as I recall.
Who do you mean by "the author" here? This seems to be a group effort by a "Rust for Linux" group, not a single individual.
[deleted]
Hey, good catch. I edited my comment to be clearer.
That makes it much clearer, thanks. There might be some quibbling over the wording of the goal and whether this technically counts as RFL being driven by the Rust Project, but the goal page [1] is at the very least a clear statement of the incentives they have to push for RFL, in their own words.
[1] https://rust-lang.github.io/rust-project-goals/2024h2/rfl_st...
[1] https://rust-lang.github.io/rust-project-goals/2024h2/rfl_st...
As Miguel said, the commitment from the Rust project is making Rust for Linux build on stable Rust, rather than using nightly. We care about that for a variety of reasons: we don't want folks to get a negative impression of Rust's stability based on nightly Rust, and Rust for Linux is a good exemplar of projects needing certain features, and it's an important effort in its own right that demonstrates the ability to incrementally add Rust to an established project.
It's up to the awesome Rust for Linux folks to work on the integration and upstreaming and policy needed to ship the kernel with Rust. And they're doing incredible work, based on the ability to write more and more kinds of drivers/filesystems/etc in Rust.
It's up to the awesome Rust for Linux folks to work on the integration and upstreaming and policy needed to ship the kernel with Rust. And they're doing incredible work, based on the ability to write more and more kinds of drivers/filesystems/etc in Rust.
It’s all open source and therefore mostly unpaid volunteer driven, but it doesn’t really feel like there is truly a policy. Every week we see a story here about a kernel maintainer complaining about Rust and Linus refusing to actually apply any sort of rules to the maintainers.
It just seems very aimless and unfocused.
It just seems very aimless and unfocused.
> It’s all open source and therefore mostly unpaid volunteer driven
The vast vast vast majority of Kernel development (and, I would guess, low-level open source software development) is paid for by companies.
Here's an example. Scroll down to "Most active 6.13 employers". Unknown+None is not even 15%: https://lwn.net/Articles/1004998/
The vast vast vast majority of Kernel development (and, I would guess, low-level open source software development) is paid for by companies.
Here's an example. Scroll down to "Most active 6.13 employers". Unknown+None is not even 15%: https://lwn.net/Articles/1004998/
I personally think Linus is making the right choice here, and not explicitly denying Rust in the kernel. Instead he is delegating it to other high level maintainers to work out the issues and make the decisions on how the integration will go. He is already so heavily involved in day to day operations in the C code, I can't imagine him being able to take on the burden of also needing to negotiate pulling in an entirely new language.
From my understanding, the current maintainers are worried about being stuck with Rust code should the Rust maintainers leave the project, and Linus is requiring that all code builds that makes it into a release (which includes the Rust code).
I am not for or against Rust being in the kernel, but I can appreciate the view of maintainers on a project of this age being concerned about introducing a second language (one which many of the C developers are not familiar with). This isn't a single company's web application project where a polyglot environment should work well when chosen for the right reasons. The Linux kernel is a backbone of modern computing, and making a decision on what to do without exploring all potential benefits and issues would be irresponsible at best. From what I've read, the Rust proponents want a piece of Rust middleware for DMA access so that each rust component doesn't need to have their own implementation, but the C maintainers don't wish to have to maintain C interface compatibility for Rust. With Linus stating that all code in the project must compile to be accepted in a release, this puts a heavy burden on the C maintainers where they are now required to work with the Rust developers fairly closely. Some of these maintainers have been around for a long time, and are skilled in C and do not wish to learn a new language for when the shit hits the fan and something in the Rust code breaks.
Again, this is just my understanding of the situation from what I've read, I may have some of this completely wrong, and if so I apologize to anyone involved.
From my understanding, the current maintainers are worried about being stuck with Rust code should the Rust maintainers leave the project, and Linus is requiring that all code builds that makes it into a release (which includes the Rust code).
I am not for or against Rust being in the kernel, but I can appreciate the view of maintainers on a project of this age being concerned about introducing a second language (one which many of the C developers are not familiar with). This isn't a single company's web application project where a polyglot environment should work well when chosen for the right reasons. The Linux kernel is a backbone of modern computing, and making a decision on what to do without exploring all potential benefits and issues would be irresponsible at best. From what I've read, the Rust proponents want a piece of Rust middleware for DMA access so that each rust component doesn't need to have their own implementation, but the C maintainers don't wish to have to maintain C interface compatibility for Rust. With Linus stating that all code in the project must compile to be accepted in a release, this puts a heavy burden on the C maintainers where they are now required to work with the Rust developers fairly closely. Some of these maintainers have been around for a long time, and are skilled in C and do not wish to learn a new language for when the shit hits the fan and something in the Rust code breaks.
Again, this is just my understanding of the situation from what I've read, I may have some of this completely wrong, and if so I apologize to anyone involved.
> From my understanding, the current maintainers are worried about being stuck with Rust code should the Rust maintainers leave the project, and Linus is requiring that all code builds that makes it into a release (which includes the Rust code).
This does not seems like arguing in a good faith. As example last 'drama' was explicitly about that PR with Rust code went into Rust branch not under C maintainer. Yet he blocked it anyway even when Rust maintainers stated, again, that any change in C API, that would break Rust code, was responsibility of Rust maintainers. Yet people (like you) are still ignoring this. Why?
This does not seems like arguing in a good faith. As example last 'drama' was explicitly about that PR with Rust code went into Rust branch not under C maintainer. Yet he blocked it anyway even when Rust maintainers stated, again, that any change in C API, that would break Rust code, was responsibility of Rust maintainers. Yet people (like you) are still ignoring this. Why?
Please see this thread, which is where I got my information from. If you have a better source, I would love to read it. I understand that you may be passionate about wishing to have Rust in the kernel, but I was not fighting for or against this. To claim that I am not arguing in good faith (I am not arguing), and then to say that I am ignoring what you've said is the actual argument in bad faith. I also stated to correct me if I'm wrong, but I will believe this thread over a comment that seems to be more emotion over fact (as I fail to see how I ignored anything, and made no claim to be an expert). I would love an actual conversation over this, but only in actual good faith.
Subject: Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction. https://lwn.net/ml/all/[email protected]/
Subject: Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction. https://lwn.net/ml/all/[email protected]/
If you read the patch, it puts no code in kernel/dma.
I probably didn't describe myself well enough. I was under the assumption that there was a Rust middleware to interface with the C API, and some of the C maintainers objected even to this because they feel they will need to be in communication with the Rust maintainer(s). I am not against Rust being used alongside, or even in the kernel. I was just pointing out some of the objections the C developers were stating.
I believe there is a middle ground where everyone can be happy, and firmly believe that the Rust maintainers in the Linux project will keep on top of the C interfaces to know when there will be changes. Going back to my comment, I realize that I presented why the C developer/maintainers don't want Rust, but that is not my own stance. In my opinion, there is enough interest in the Rust for Linux project that acting as though there is only a single maintainer, and if they disappear the entire project fails and all Rust code stops compiling is unrealistic and FUD.
I can see a whole host of problems being tackled, especially in driver development and safety concerns, by using Rust. I feel the C maintainers are acting as if the entire kernel is going to be rewritten in Rust in a timeframe where any of these people would still even be capable of using a keyboard or not suffering from severe dementia.
My apologies to anyone that thought I was pushing for one side or the other, I was only repeating the recent "drama" that I heard was going on, and I respect both sides.
I believe there is a middle ground where everyone can be happy, and firmly believe that the Rust maintainers in the Linux project will keep on top of the C interfaces to know when there will be changes. Going back to my comment, I realize that I presented why the C developer/maintainers don't want Rust, but that is not my own stance. In my opinion, there is enough interest in the Rust for Linux project that acting as though there is only a single maintainer, and if they disappear the entire project fails and all Rust code stops compiling is unrealistic and FUD.
I can see a whole host of problems being tackled, especially in driver development and safety concerns, by using Rust. I feel the C maintainers are acting as if the entire kernel is going to be rewritten in Rust in a timeframe where any of these people would still even be capable of using a keyboard or not suffering from severe dementia.
My apologies to anyone that thought I was pushing for one side or the other, I was only repeating the recent "drama" that I heard was going on, and I respect both sides.
It's not that it's volunteer driven (which it is not, as the siblings have pointed out), it's that it's distributed governance without the central authority enforcing a vision.
Most development in this space (toolchain and kernel) is funded in some way. I don't know if this particular project is at some strange intersection where this isn't the case, but I would be surprised.
Writing policies hard, and the environment here is somewhat challenging.
Writing policies hard, and the environment here is somewhat challenging.
I agree it’s no easy task. It seems to me though, as an outside observer, that writing virtually no enforced policy is the lazy way to go about it. Write a policy, stick to your guns, have a procedure for changing it if you get it wrong.
The people who contribute to kernel and especially maintain the subsystems are some of the most well-paid developers out there. If they are not a principal engineer somewhere, they have their own lucrative consultancy business.
My guess is someone needs to step up and be the Linus of Rust code for Linux. It's the kind of thankless task that is invaluable, whoever can muster the courage to do it will be vital to Linux/Rust.
> someone needs to step up and be the Linus of Rust code for Linux
No. Better to have just Linus for Rust. Write a new OS in Rust unencumbered by C curmudgeons. As a bonus it won't be thankless but pretty exciting project on work on.
No. Better to have just Linus for Rust. Write a new OS in Rust unencumbered by C curmudgeons. As a bonus it won't be thankless but pretty exciting project on work on.
OS part is easy, there's an OS behind every other sofa in your closest university with software engineering classes. Getting people to write drivers for it is the hard part. Most OSes never boot outside of qemu.
Such new OS exists already (Redox). It's actually really good and can run modern DEs (Cosmic) and some recent commercial games (Balatro).
The problem with this direction is it dooms Linux to obsolescence. Thanks to Rust's memory safety, Redox has achieved a level of security and crash-resistance that Linux cannot hope to achieve with C. With everyone (including the US Govt) pushing for memory safe code, this has a negative impact on the whole world's major investments into Linux.
To mitigate the sunk costs, Linux needs to compete on memory safety. C has no viable solution so Rust is the only option.
The problem with this direction is it dooms Linux to obsolescence. Thanks to Rust's memory safety, Redox has achieved a level of security and crash-resistance that Linux cannot hope to achieve with C. With everyone (including the US Govt) pushing for memory safe code, this has a negative impact on the whole world's major investments into Linux.
To mitigate the sunk costs, Linux needs to compete on memory safety. C has no viable solution so Rust is the only option.
> To mitigate the sunk costs, Linux needs to compete on memory safety. C has no viable solution so Rust is the only option.
Isn't Zig designed as a viable solution? IIRC being easily compatible with C is one of its features.
Isn't Zig designed as a viable solution? IIRC being easily compatible with C is one of its features.
Probably depends on what exactly you're looking for in a viable solution. Zig does not provide the same level of memory safety as Rust does (IIRC it doesn't protect against data races and doesn't offer (complete?) temporal memory safety), so if what Rust provides is the bare minimum you want Zig won't cut it.
Unfortunately it won’t matter if the C and only C developers block generic language interoperability interfaces…
Despite starting off "not big and professional like gnu" Linux now has trillions of dollars' worth of business going over IT infrastructure based on it. You bet your ass it's a corporate funded behemoth now, not unpaid volunteer driven. And with corporate money comes corporate governance. Ouster of Linus as the chief maintainer is definitely on the table (though not likely to ve exercised here and now). I think Linus is being wishy-washy so as not to anger either the traditional "C-niles" currently holding the kernel together or the Rust group, who are likely a more prolific source of new development.
The right call here is to tell Ted Ts'o and the other old guard that they need to adjust to the new Rust reality, because things like being explicit about object lifetimes will make the C code better as well as more compatible with what the Rust side wants to do. But he either doesn't want to do that or is looking for a diplomatic way to go about it.
The right call here is to tell Ted Ts'o and the other old guard that they need to adjust to the new Rust reality, because things like being explicit about object lifetimes will make the C code better as well as more compatible with what the Rust side wants to do. But he either doesn't want to do that or is looking for a diplomatic way to go about it.
The CC list is interesting:
https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ...
Summary: Why Rust Cannot Be Fully Integrated into the Linux Kernel
Rust-for-Linux (R4L) is an experiment, but it faces fundamental obstacles due to the Linux kernel’s monolithic structure, constantly changing APIs, reliance on GCC, and existing development model.
Key Challenges: 1. Unstable Kernel APIs – Linux kernel APIs frequently change, making Rust integration difficult without a stable ABI, which contradicts Linux’s development model. 2. GCC vs. LLVM Conflict – The Linux kernel primarily relies on GCC, while Rust requires LLVM. This creates fragmentation in the toolchain. 3. Dual-Language Complexity – Developers must master both C and Rust, leading to recruitment and maintenance challenges. 4. Memory Model Incompatibility – Rust’s ownership model does not align well with many kernel subsystems, requiring workarounds that reduce its safety benefits. 5. Monolithic Kernel Issues – Linux is designed as a monolith, where all components deeply interact. Introducing Rust without a complete rewrite results in complex dependencies and maintenance overhead.
Only Viable Solution: A Full Fork
A Rust-based kernel requires a complete fork from Linux, rewriting everything in Rust. However, such a project would no longer be Linux but an entirely new OS.
Thus, Rust cannot become a true part of the Linux kernel without fundamentally breaking its principles. The real question is: Should a new Rust-based OS replace Linux, or should Rust-for-Linux be abandoned?
Rust-for-Linux (R4L) is an experiment, but it faces fundamental obstacles due to the Linux kernel’s monolithic structure, constantly changing APIs, reliance on GCC, and existing development model.
Key Challenges: 1. Unstable Kernel APIs – Linux kernel APIs frequently change, making Rust integration difficult without a stable ABI, which contradicts Linux’s development model. 2. GCC vs. LLVM Conflict – The Linux kernel primarily relies on GCC, while Rust requires LLVM. This creates fragmentation in the toolchain. 3. Dual-Language Complexity – Developers must master both C and Rust, leading to recruitment and maintenance challenges. 4. Memory Model Incompatibility – Rust’s ownership model does not align well with many kernel subsystems, requiring workarounds that reduce its safety benefits. 5. Monolithic Kernel Issues – Linux is designed as a monolith, where all components deeply interact. Introducing Rust without a complete rewrite results in complex dependencies and maintenance overhead.
Only Viable Solution: A Full Fork
A Rust-based kernel requires a complete fork from Linux, rewriting everything in Rust. However, such a project would no longer be Linux but an entirely new OS.
Thus, Rust cannot become a true part of the Linux kernel without fundamentally breaking its principles. The real question is: Should a new Rust-based OS replace Linux, or should Rust-for-Linux be abandoned?
Any doctrine similar somehow never made it, unless the prog lang is scheme or guile or racket but i consider Tcl a lisp in disguise.
My prediction:
Linus will retire and leave the Rust mess for other to live with.
Linus will retire and leave the Rust mess for other to live with.
The most likely replacement for Linus as BDFL is Greg KH, who is also friendly (if anything, friendlier) towards R4L.
ChocolateGod(1)
andrewstuart(3)
Please fix rust to make its toolchains statically link libgcc. Bug since 2015...
They don't say what their policy is regarding building the C parts with GCC and the Rust parts with the LLVM toolchain (including the Clang parts that bindgen uses). Some kernel developers are very much opposed to mixing GCC and Clang in a kernel build (to put it mildly), and some version combinations are known not to work. On the other hand, it seems somewhat unlikely that distributions would abandon building the kernel with GCC just to be able to use drivers written in Rust.