'Key kernel maintainers' still back Rust in the Linux kernel, despite the doubters The Rust for Linux project is alive and well, despite suggestions to the contrary, even if not every Linux kernel maintainer is an ally. On Sunday, Miguel Ojeda, who leads Rust for Linux and contributes to Linux kernel maintenance, published a "Rust kernel policy" clarifying the status of efforts to integrate Rust code into …
I'm not a fan but Java is, by most measures, still today one of the most successful and widely used languages of all time largely because of that 'run anywhere' feature. Unlike Rust it isn't appropriate for the Linux kernel of course.
https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/
https://invozone.com/blog/top-10-programming-languages/
Nah the exact same API problem would exist. There are some ease-of-use features that make interfacing Zig and C more automatic, but it's really not that different in Rust with bindgen. The complaint/issue is that if a maintainer changes a C API they then feel responsible for having to change C, or Rust (or Zig) code which relies on it, and they're happy to do that if it's C code but not necessarily if it's Rust (or Zig) code that they're not familiar with. Just having bindings refresh automatically might not be enough. In any other project you'd say nail down the damn APIs already, but it's the Linux kernel, they arguably have good reasons not to and that's worked okay so far.
Zig is a decent C replacement but I don't believe it makes as good a complement to C as Rust does in something like the Linux kernel (mainly but not only because of the memory safety Rust brings).
And what % of global java developer staffs did you interview with ?
Look at the salary surveys. Java developers generally earn less than C and C++ programmers.
Hence they represent a cheaper resource cost for biz.
And the language itself supports that by filing off many of the sharp corners that catch under qualified programmers. The skill level to produce "working" code is much lower.
I don't doubt there are high quality shops, but my main point is that ...
the reason the majority of shops employ Java is because it is the lower cost, lower effort option.
Few care about the build and deploy characteristics of the Java platform.
Java became popular because people love the JVM not the Language.
It's had lots of cash spent making it mostly usable and there is good tooling targetting the JVM - they could care less what the DevExperience is for your SkyBox which is running a JVM for the UI.
Myself not being someone for or against Rust in any way (and also being someone that hasn't really worked on an C/C++ codes in many, many years), I can understand Hellwig's reasoning, if I properly understand what the Rust developers are trying to do. Personally I've never even looked at Rust, so I only know about the anecdotal comments (largely discussing how it provides better memory safe operations).
As I understand it, the Rust developers want to essentially create a C-to-Rust mapping for the DMA API functions, which would let them call that functionality from within Rust in the same way you can call it from C. They've said they would maintain the Rust side of those mappings. On the SURFACE, that might sound reasonable enough.
Where the problems come up are if someone needs to change the DMA API functions in an incompatible way (e.g. adding an additional parameter). If someone on the C side of Linux tries to make that change, it can break something on the Rust side (of which they are not a part). Now the C developer has to work with a Rust developer to get their side updated to make his stuff work without breaking something he doesn't even deal with (and possibly can't, if he doesn't know anything about Rust). If the particular breaking changes requires a lot of work on the Rust side, the C developer would be stuck and waiting.
Assuming this is the crux of the matter, I can see how this can slowly turn into a maintenance nightmare and hinder development. It's similar to how when someone publishing a REST API makes changes to the way something is called or how data is returned. Any number of third party people could be calling that API, and aside from making a v2.0 branch, the publisher's ability to make code changes/enhancements shouldn't be hampered by the others that are using it.
Indeed, though it's worse than that.
The Linux kernel project has a few core policies:
1) "We don't break userspace." External APIs must remain stable, deprecations and removals take many years.
2) Inside the kernel, change what you need to
3) If you change an internal API, you're also responsible for updating everything using it. "You break it, you fix it".
Which means if this maintainer had accepted the change, that means maintaining Rust code forever. Their team does not have the expertise to do so, and thus cannot accept it.
I wish (1) and (3) were more commonplace in commercial settings too, really. I've had far too many cases where another team made a breaking change and didn't even document it, let alone offer example shims or patches.
The original intent of "Rust in the kernel" was for things like drivers running in kernel-mode, where it's actually using the external stable APIs but avoiding the userspace transition for performance. Potentially very valuable.
This post has been deleted by its author
> Now the C developer has to work with a Rust developer to get their side updated to make his stuff work without breaking something he doesn't even deal with
Shock, horror! You're modifying something that someone else has built things around, and it half breaks! Now you have to work with them (or yet another else) to get things working again, because you can't be bothered to learn how it works.
What's the problem? Should I be able to change the printk implementation to require an extra parameter, without updating every call to it everyplace else in the kernel? just expect it to work, or go on a technical news site and complain about how I can't make my simple change without everything breaking?
The current maintainers don't have the experience to fix the things, and some of them are thus not accepting the things. That's fine. You want your things in, but the maintainer won't accept them? Talk about replacing the maintainer, or sharing their job. The rustolians are acting like they just graduated high school and have never had to work with anyone else before. Some maintainers are acting a bit snobbish, just a bit, and they should stand down if someone qualified steps up to fill their role, plus the extras that are becoming necessary. Until that latter part, no one can really complain.
>>they should stand down if someone qualified steps up to fill their role
That will take a few years... there are (likely) no Rustitarians with 20+ years of kernel coding experience (and yes, kernel space code is very different to userland code; its all C but there is a different mind-set required for the coding AIUI) who are as proficient in Rust as they are in C (or vice versa depending on where they cut their teeth). Until there are some (one isn't enough - that's a "one-man-bus" risk plus a bottle neck), Rust in the Linux kernel (for other than drivers) will be, err, unlikely.
>>Until that latter part, no one can really complain.
Unfortunately the Rustitarians seem to resort to social media rather than reasoned argument and, indeed, some of the existing maintainers are, shall we say, vociferous in their responses (becasue they have better things to do than wash dirty linen in public)
20+ years of kernel coding experience
C'mon, it's not that esoteric. Every comp sci graduate has done some kernel courses. There are a few key differences in memory usage, robustness, interrupts, weird low-level device specific interfaces to read up on, and you need a good understanding of the hardware in general (as in any performance sensitive or low-level code) and for sure those take a decent amount of development time to get a good grip on, but not 20 years for anyone with a decent innate ability for this sort of stuff. How many years kernel coding experience did Linus have when he first wrote Linux? I don't think Dave Cutler even had 20 full years kernel hacking when he conjured up NT.
(I also find it hard to believe no one already with 20 years on the Linux kernel has yet made the effort to learn Rust, but maybe I'm overestimating them).
This is true with any downstream code. Any driver using dma, for instance, could break with an upstream change.
There is a difference because this is in Rust. The maintainer needs a rust tool chain installed or they will not find out about the breakage to latter. The rust for linux people have offered solutions -- either add a new maintainer to the system, or accept some breakage in staging because Rust for linux is new, where the rust-for-linux folks will fix it. Over time, the expectation would be that the former of these will become the main route.
It is inevitable that the introduction of any new language will come with some cost, as would the introduction of any new tool chain (such as clang). The question is whether the value is greater than the cost; eventually that decision will have to be made on a whole kernel basis but for now, it appears to be one subsystem at a time. I can see why some people get a bit frustrated with this.
not true with "any" downstream code. if the downstream is written in C, then you have options to make api changes compatible, with a recompile of your interface code. doing that with a second language and build toolchain is the tripping point, as Helliwig said.
The difference being? I mean, you can just recompile the Rust code to.
I agree that there might be changes that are source level compatible changes in a C API -> C client situation that are not source compatible in a C API -> Rust client situation. How frequently will that happen.
> The difference being? I mean, you can just recompile the Rust code to.
Why would a C developer have the Rust toolchain on their system to do such a recompile? They are C developers, not Rust developers.
Even if a C developer had such a toolchain installed, why would they know how to use it or diagnose (let alone fix) any errors it throw? They are C developers, not Rust developers so they don't have that knowledge.
They are C developers, what happens in Rust-land is none of their care. Apart from the fact that Rust developers are whining on social media about this and whinge that the C-devs that should care and they (the C-devs) need to be responsible to the Rust code, y'know, something the C-devs don't actually care about or have the skillset to do because they aren't - you guessed it - Rust developers.
It's just not their job to care about Rust (because for many of the devs, it's not a job).
Why would they have a rust toolchain? Because they are kernel developers and having a rust tool chain enables them to see breakages early.
Why would they know how to use it? They don't need to know that. You install it, and the build system uses it.
Why would they know how to fix errors? They might, they might not. If they don't, then there are options, including adding a new maintainer who takes care of the Rust part, or they ask the r4l people, or in the extreme cases they leave it till it breaks in staging and it will get fixed there.
No one is arguing that adding a second language comes with no cost at all and to expect that is unreasonable. Yes,overtime, it is likely that the main scalable approach is for many maintainers to bite the bullet and learn enough Rust to maintain the safe abstraction. Would you be worried about that? Learning a new language is not that much of a biggie, compared to the technical expertise required to work on a kernel in the first place.
> Learning a new language is not that much of a biggie, compared to the technical expertise required to work on a kernel in the first place.
It is entirely unreasonable to demand that people who have worked for decades on a project in C, entirely unpaid, to go and learn Rust because some idealogue said so.
I'm really not sure why you are finding it hard to understand:
Rust in the kernel is not the problem of anyone else than the R4L developers.
It is not the responsibility of any maintainers outside the R4L project to assist with that or enable it in any way.
It is the responsibility of the R4L developers to make Rust work. No-one else. No other maintainer has any obligation or responsibility to assist the R4L project at all.
If the R4L developers want Rust in the kernel, then they need to make it work, not the C maintainers.
As I've seen it mentioned elsewhere, the R4L developers should have just sat down and written a Rust-first clone of the Linux kernel rather then trying to insert Rust into the Linux kernel. Otherewise, the only way I see the Linux kernel being migrated to Rust is when long-time maintainers retire/resign/die/lose interest and get replaced over time with developers who already understand both C and Rust when they come into the projects.
So, "Move Fast and Break Things", eh?
Might be OK for fElon Muskrat, or the developers and I use the term very loosely of Teams, but not a good plan for any operating system, much less one that has rightly earned a reputation for not being shit.
Given that this type of situation was entirely predictable.. then why on earth did they think it was technically feasible to introduce a 2nd language that was unable to read and apply existing C header files ?
They knew Rust couldn’t handle C header files, so they knew that interfaces would have to be manually maintained, so they knew this situation would come up often.
It’s almost like they deliberately set out to make the existing kernel unmaintainable, so as to force a complete rewrite/takeover at some point.
They thought it was technically feasible because what you say isn't true.
Rust uses a tool could bindgen which, well, generates bindings automatically based on the C header files.
It is not these interfaces that are being manually maintained. It is the safe abstraction that is being maintained.
Think of it like this. A C function might return a pointer. The Rust bindings will also return a pointer. But that is problematic because in Rust all pointers are unsafe, because Rust cannot know whether the pointer is still alive, or even if it is guaranteed to be a pointer rather than just null. That semantics is not in the C header; if it is anywhere it will be in the documentation, or else it must be inferred from the reading the C code.
Rust in the kernel could leave every Rust client to make that decision for itself. Or it could provide a single safe abstraction that, for example, distinguishes between a value that is known and a value that might also be null. Downstream clients of the Rust safe abstraction can now use safe Rust.
Your last sentence does not really make sense. Why would the Rust in linux folks, many of whom have been long term kernel contributors from before r4l was a thing, want to make the project they are working on fail?
There are too many magpies in software development. Too many force the new thing because it's shiny and "so much better" than what is there, but only based on how new and shiny it is.
Everyone, really, wants the best. But something that can upend decades of work needs proper consideration and it has to be accepted that the new shiny thing might not be the best fit for something that's already in place. Likewise, after that consultation and considered approach, if it is an improvement then it must be accepted.
Everyone wants the same thing but everyone needs to understand someone is not going to get what they want. The acceptance, or lack of, is the problem.
Anyone remember how the Linux kernel project used to be a small self-funded group of anti establishment hackers, who never seemed to sleep ?
Now it looks like an overstaffed sheltered workshop run by 100 different government departments
It’s literally turned itself into some sort of C++ steering committee, or corporate SAP rollout before our very eyes
It reminds me of the closing scene in Orwell’s Animal Farm, where the starving but “liberated” farm animals get to peek through the window, and see their comrade piggies sitting at the table wearing suits, feasting, laughing and drinking wine with the farmers
I'm pretty sure Rust is here to stay, but as with systemd and with the NVidia shim there are going to be those who gnash their teeth and scream their fury for years, if not decades, to come.
The status quo is not good enough. It requires too much manual care and attention to code structure and behavior, and is far too prone to mistakes.
Instead of trying to graft Rust into existing Linux kernel code why not use Rust to build a functional clone of the kernel? It doesn't have to include all the capabilities of the current kernel, especially the ability to support numerous processor types, but it would demonstrate the viability of Rust and be the spearhead for a changeover project. The current approach seems to risk cherry picking modules that are relatively easy to change so risks turning a coherent piece of code into a bit of a dog's breakfast of competing styles and methodologies.
I'm not opposed to including Rust but at the same time I don't like to see prototype anything included in production code just because its "new and improved". My experience is that the piecemeal approach rarely works out in practice.
One word: Cost. Look up "cost of redevelopment of the Linux Kernel".
There is also time ... how many man-hours over how many years do you have to devote to this project?
And then, when you are done, you'll have a Linux Kernel in Rust that is several-to-many years out of date, depending on which kernel version you are targeting.
See ReactOS for a project similar in scope.
Note that I'm not saying it couldn't, nor shouldn't, be done! That's up to you. I'm just pointing out (some of) the logistics that might get in the way.
That's falling into the Windows trap**. An OS is built from components, most of which are just applications. The kernel itself is quite small. The labor involved in doing this work won't be wasted because obviously the components should all drop in to replace existing components but the work should expose any shortcomings before they end up compromising a system that many people rely on.
(**Windows is a large black box of 'stuff' that's constantly being changed in a sort of software version of Whack-a-Mole -- you never quite know what you're getting with each release. Linux, being Unix based, was conceived as modular, being built from interchangeable components.)
(Anyway, I can understand why there's some pushback from kernel maintainers over Rust. The fact that Rust advocates don't seem to understand this, just labeling skeptics as "old and in the way", suggests that Rust likely has some way to go before it can be trusted.)
I believe the new operating system Redox would be a much more welcoming place for Rust enthusiasts to focus there efforts. in conjunction with the COSMIC desktop seems to be most of the way there.
Redox, being a microkernel, fulfils the promise of GNU HURD did. Did you know that Linux was only ever intended as a stopgap by the GNU project? Shame Redox is MIT licensed not GPL.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
