"Torvalds said that it is not necessary to understand Rust to let it into a subsystem; after all, he said, nobody understands the memory-management subsystem, but everybody is able to work with it."
Chuckled a bit at this line, anyone have context on how true this is?
"Torvalds said that, for now, breaking the Rust code is permissible, but that will change at some point in the future. Kroah-Hartman said that the Rust developers can take responsibility for the maintenance of the abstractions they add."
This need some very good expectation management.
For most driver or subsystem, maybe you don't need to know how mm works.
Rust is different. The kernel Rust teams are trying to encode some safety invariant. If any of those mismatch with the C side, it breaks. Those invariant need some non trivial knowledge of rust to understand
Is there an example of what you're describing?
There’s a recent drama where the Rust folks asked some people to clarify some of the semantics of some of the filesystem APIs, and this request wasn’t taken well. There’s been a bunch of hn threads about it.
like which?
not sure if this is what the op referred but like this one https://news.ycombinator.com/item?id=41450347
didn't find threads that regarding "clarify APIs semantics", but kernel docs are indeed not in a very good condition. Since C does not provide same level of soundness that Rust does, there are many hidden traps.
asahi developer had a good discuss about this https://threadreaderapp.com/thread/1829852697107055047.html
This overall situation is, yes. And the stuff from Lina is related, thanks for also pointing that out.
I apologize, I am on my phone, so rather than curating links, check out https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu..., most of which are about this situation.
I'm kind of shocked that C has defined memory behavior. Wouldn't this vary per arch and compiler?
It's very probably true in the totality of "as expressed in a real build for all configurations and architectures", too much variation of behavior to have the whole map in mind at once. You can work through it potentially, and I'm sure a few come close, but others will have things top of mind that experts don't.
It’s an opinion, but it sounds very good from the perspective of treating the relationships between system and subsystems as an interface to be managed.
It's true in the sense that nobody understands it well enough to avoid writing memory safety bugs.
A lot of kernel resources are managed through infrastructure like devres:
https://docs.kernel.org/6.0/driver-api/driver-model/devres.h...
These days it's entirely possible to write a decent driver with only the foggiest idea of how memory management happens in the kernel.
Aside: LWN is basically what ChatGPT summarization as advertised itself to be, except it's actually good and coherent and useful. I can trust Jonathan to summarize the conversation in a way that is mostly sane and reasonable in a way that I can never hand off the job to generative AI. It's an important area where humans seem to excel over computers.
Also, just to have some content that is actually on-topic: is anyone actually shipping upstream Linux Rust code yet? I understand that some stuff is slowly merging in but I'm not sure if it's actually being exercised yet.
I believe the kernel graphics drivers for the Apple M1 are written in rust, and are upstreamed.
>Changing C interfaces will often have implications for the Rust code and may break it; somebody will the have to fix the problems. Torvalds said that, for now, breaking the Rust code is permissible, but that will change at some point in the future.
I think this is the main technical change needed from the Linux kernel. It needs a layer of quasi-stable well documented subsystem APIs, which ideally would be "inherently safe" or at least have clear safe usage contracts. And it's fine for these interfaces to have relaxed stability guarantees in the early (pre-1.0, if you will) experimental stages. Changing them would involve more work and synchronization (C maintainers would not be able to quickly "refactor" these parts), but it's a familiar problem for many large projects.
It's the only reasonable point from the infamous tantrum by Ted Ts'o during the Rust for filesystems talk, everything else, to put it mildly, was a really disappointing behavior from a Linux subsystem maintainer.
For those curious, this is the link[0] to the filesystems talk with the relevant timestamp. A bit more was discussed in this[1] article as well about Wedson Almeida Filho leaving.
Why do we need quasi-stable anything within the kernel? Wouldn't a much better long-term solution be changing the rule to "break whatever APIs you want, but you have to fix all of the in-tree Rust uses too"?
The problem is that some high-profile people who want to preserve their right to "break whatever", do not want to shoulder responsibility of fixing Rust code which depends on the broken stuff. Even worse, they even do not want to explain and document semantics of existing APIs (sic)! See the video linked in the sibling comment.
Speaking more broadly, freely breaking stuff in large projects is dangerous, since fixing stuff may require a more specialized expertise and knowledge, e.g. being well-versed in Rust safety rules, knowing some obscure information about hardware behavior, or being aware about some tricky invariant which must be preserved by the code. This is why changes in API boundaries often require synchronization between different teams.
On a semi-tangent, does anyone happen to know how Microsofts push to use Rust in the Windows kernel is coming along? They rewrote some components in Rust and rolled them out to production about a year ago but it has seemed pretty quiet on that front since then, unless I missed something.
I noticed the other morning that they’ve either re-written or are growing the win32k driver in rust. This was either in Server ‘25 or vNext though I can’t remember.
Given win32k implements a good chunk of the kernel-mode graphics and windowing system it’s a pretty good place to start that effort.
edit: win32kbase_rs.sys was what it was called, and I’m pretty sure it was 2025 I pulled it from but it might be on earlier versions too
Out of curiosity, how did you notice this?
I was hunting for what Windows libraries used a particular new API and saw it in my scrolling!
You can see all the panic and error strings, and some internal package paths if you run strings over it. Win32k looks like it got split pretty hard into a couple of sub libraries in recent versions though (win32k, win32kbase, win32kbase_rs etc)
I googled for this file and I LOL'ed as the first link was a crash report linked to this one.
https://www.elevenforum.com/t/latest-beta-causing-program-cr...
They haven’t spoken publicly about it. As a Windows user, I am very intrigued!
Thought that ThePrimeTime in his video https://youtu.be/62oTu9hjxL4?si=E98WZ0zJSNUC8TEH&t=287 hit the nail on the head re: Rust versus C.
Max level C programmers, have designed their programming style around control down to the absolute bit. C derives control from absolute control over behavior.
Max level Rust programmers have complete mastery of types. Rust derives control from types.
Seems somewhat philosophically incompatible.
It is a good video, but I'm not at all convinced that a philosophical "authoritarian" vs "anarchy" difference between Rust and C actually exists. C programmers work through all sorts of constraints and rules on how to correctly use a system, same as anyone else. Heck, there are hundreds of pages of kernel documentation explaining how developers are expected to use the various locking subsystems. Does that make C authoritarian? I don't think so... that's just a fact of programming. The details matter.
IMO the only real cultural difference in Rust is that you are expected to explain those constraints through the language of the type system, not just in English. That's a lot of work up front but it also gives you way more automation down the line (eg checking that you used a mutex correctly via rustc rather than through emails to Linus Torvalds). Some people definitely take it too far, and blow up their code with endless incomprehensible traits. But the islands aren't incompatible, it just takes work and skill to bridge them.
> Does that make C authoritarian? ...
Well, he called Rust authoritarian and C anarchy. As with all analogies if I don't stretch too far it does make lot of sense to me.
Sure! I'm just disagreeing that "C is anarchy because anyone at any point can do anything". You can't do anything, Linus will eventually yell at you in an email. To me, the only philosophical difference is that Rust wants to automate Linus
That would also explain why Linus is on board with it, A thousand rust compiler instances is way more efficient than one Linus instance yelling at people, plus eventually he won't be there anymore.
This is less true in "how the language works", and more true in "code I have read in these languages follow these patterns". The latter I agree with, the prior less so. Rust is more type heavy sure, but there are plenty of type shenanigans in rich enough C ecosystems, the kernel has plenty of vtable structures which have varying level of richness and type complexity in their own C expression. Ever worked with the addr types in the BSD sockets API - super messy types that can be a real pain for FFI for example, heavier typing exists in C - not "higher order" and so on, and yes you _can_ do that in rust, but do you want to debug it in kernel use cases, maybe not. Rust kernel code may look different in the end from a lot of other Rust code in a similar way to some C code in the kernel being quite different from other C code elsewhere.
Good C code will select a rigid set of patterns, carefully chosen to maximize safety, and stick to them. It makes a lot of the bug prone patterns stand out.
This is somewhat like what a higher level compiler can produce, but more manual. It's reliance on code smell instead of a type checker.
IDK, I thought well-written c and c++ had the same notions of ownership and lifetimes, just not enforced by the compiler
No, C++ and especially C have much looser notions around ownership and lifetimes. They still require the basic idea of temporaral safety at all times, but differ greatly in how that's achieved in practice. For example, you'd typically share an Arc<RwLock<T>> between threads in rust, even if it doesn't strictly need them for whatever reason. I can't say I've ever seen someone manually implement Arc in C, and RwLock might be ensured half a dozen ways spanning the entire gamut from no protection for things like file handles all the way up to full mutexes.
There are dozens of Arc implementations in the kernel. Atomic reference counting is an important way to manage lifetimes and is used extensively in things like making sure that shared resources (files, pages, …) are managed correctly.
I think that's misunderstanding their point a little bit?
I agree with them that in any well-written program (in any language really, not just C and C++) the ownership and lifetime constraints are not necessarily enforced by the compiler - that is, they are not expressed through types or even necessarily through code at all - but they are definitely existent in the design and behaviour of the system. If the programmer cannot explain who holds what and for how long, and therefore when it's safe to read or write particular resources, then that isn't well-written code IMO.
> I can't say I've ever seen someone manually implement Arc in C
...an Arc is literally just a shared pointer. It's in the name, Atomically Reference Counted. Reference counted resources that use atomic operations to adjust the count are a dime a dozen in C projects in my experience.
Rust did not invent the concept of a multiple-reader/single-writer lock either, e.g. the Linux kernel has the `rw_semaphore` type. I don't understand treating types like this as something arcane simply because they're given an explicit tag in Rust.
The rust notion of lifetimes is one of the most c++ things I've ever seen. I've always assumed it grew out of the same culture that produced c++ smart pointers and RAII.
> I can't say I've ever seen someone manually implement Arc in C
In C++, shared_ptr in the standard. But this was common even before the c++11 standard introduced that. I've rolled my own before, more than once. Microsoft ATL had CComPtr.
It wasn't surprising to me either that rust came from Mozilla, which made heavy use of COM, an object model that is very heavily based on reference counting.
C and C++ are very different. I think Casey Muratori hits the nail on the head here:
In short, RAII and smart pointers and borrow checker are all signs of "individual element thinking" and that way lies madness. You smear out lifetime and ownership so badly that it practically by definition becomes a problem.
Your goal is to think about this stuff in groups to make thinking about allocation way, way easier. Programming is all about abstracting to the next layer.
I'm not sure he has quite gotten to the heart of the issue, yet. However, a bunch of smart people (Casey Muratori, Jonathan Blow, Andrew Kelley, etc.) are all dancing around something that Rust and C++ don't seem to fit the bill on. Hopefully they can crystallize it out so that everybody can see it.
I took my time to watch part of this. I don't entirely agree, however. I'm not really a large systems programmer (I'm a scientist, actually). I really do like the group oriented thinking, but it does seem like there is space for "individual element thinking" at times. This sounds a lot like the philosophical notions of reductionist thinking vs. holistic thinking which is something I think about a lot when it comes to science and physics in general. The way of thinking I've come to value most at this point in my life for understanding the world that might sound a bit silly applied to this is a synthesis (so called hegelian dielectic), which is this case for me means that reductionist thinking and holistic thinking are not really opposites but are simply modes of mental modeling, and can be apply in different ways and different times to your code. Sometimes, it is valuable to have simple, self-contained types which is reductionist or individual element thinking. However, nests of pointers are always much more complicated and unnecessary than programming at the system level for a group of related objects. Which you use depends on the context, and I don't really like identifying them as opposing forces more than different modes that can be drawn from at different times.
That said, most of the time, I find myself utilizing group oriented thinking in my codes and I avoid atomistic, reductionist thinking whenever analyzing a problem at a first pass, but reductionist reasoning does help at times, it just depends on the problem and the context. It is also true, unfortunately, that in science teaching at least we teach students to be reductionist first, and then that reductionist thinking clouds their understanding and it is something young scientists need to break out of at some point, and some never do break out of it. May be in that way it's similar to what this person refers to here (n vs n+1) I just didn't also get stuck thinking reductionism is always bad and avoided it as a rule but I draw from both sides, so to speak.
Oh interesting. I was expecting to see nonsense in that video (probably triggered by the first line -- C and C++ are basically the same thing, in that you can, and folks did forever, implement all the C++ fancy stuff in C -- just because something isn't in the core language, doesn't mean it wasn't done).
But actually it's suggesting how I've been wanting memory to be managed for a couple decades (and have achieved long ago in C projects). Basically some sort of "domain-orientated arena allocator". A simple example is in a network server -- you receive a request from a client, do a bunch of stuff to service that request, and now you're done. Please blow away the memory used to service the request, thanks, all at once. Of course it's not quite that simple because there will be some "chaff" objects thrown off in processing the request that we need to keep around for a while later (e.g. for logging to drain).
I suppose the reference to Jonathan Blow should have been a clue that this would be something worthwhile.
Casey writes games. Of course to him everything ought to be an arena allocator. This is not actually the best way to write all software.
That's a bit glib. Games almost always have significant networking component nowadays.
And Andrew Kelley writes compilers. And arenas still appear to be superior.
Games and compilers seem to do better with custom allocators. Embedded almost always static allocates. GPU workloads generally don't have "heap-like" allocations either.
We have an increasing amount of evidence that "malloc-like" or "heap-like" allocations on an individual level seem to be a net negative.
My gut feel, as someone with a grey beard, is that we're looking at a breakpoint like we did with garbage collection.
Garbage collection absolutely suuuuucks until you get big enough memory that you can overallocate by about a factor of 2 at which point garbage collection flies.
I think we're at a similar point in "systems programming". It's now okay to overallocate, overcopy, and especially overcalculate things due to current CPU architectures. Chasing pointers is now mega-bad so vtables and the like are becoming a performance bottleneck.
Embedded almost always static allocates is outdated, like integer is almost always faster than floating point.
Some embedded nowadays has hundreds of megs of RAM, with its application using mmap, out of an overcommitted virtual memory.
> C and C++ are basically the same thing
I disagree here. For example, try writing something that does reference counting in C vs C++. In C++, it's practically trivial. In C, it's a nightmare of bugs. RAII support being directly in the language is huge in this case.
Rust can do these things. It is maybe true that culturally many Rust programmers do not. There’s both good and bad reasons for this.
The point is that many of the problems rust aims to solve become much less relevant. For example, if your program only does 10 Malloc and frees, you can probably track down the memory bugs.
I agree that these techniques help you write better code, but enforcing something is better than not. Obviously it’s a spectrum, so I wouldn’t say doing that is bad, but it does not really mean Rust is irrelevant.
And Rust brings more to the table than just the borrow checker.
Sure, it just invalidates the impending doom, ban C programming narrative.
I’m not sure I would characterize it this way, but it doesn’t satisfy the criteria of “memory safety by default,” which is what more and more organizations are desiring.
Time will tell.
> RAII and smart pointers and borrow checker are all signs of "individual element thinking"
I'd call it object-oriented thinking. To me Rust and modern C++ are attempting to "OO-ify" systems programming and I think you get push back from folks who view their resources more holistically.
Even though I don't use Linux in my projects, Rust on Linux is extremely important to convince others to use Rust. I hope it succeeds.
Even though I don't write any Rust, I still think Rust on Linux is important. I rather learn and deal with Rust than with C/C++, and I too, hope it succeeds.
C/C++ is like water/alcohol; certainly they look very similar to an uninvolved observer, and one can mix them easily, but they differ drastically. One is an utterly simple life substrate, another is a toxic and hallucinogenic but potent rocket fuel.
For the record, Torvalds has always vehemently resisted any attempts to use C++ in the kernel. I completely support his position.
You are probably writing your comment via lots of software written in C++. It's a great language with lots of flaws introduced by legacy decisions that would be made differently today.
Can anyone explain to me why these two issues aren't considered deal breakers for introducing Rust into the kernel?
1. It doesn't map almost 1:1 to assembly the way C does, so it's not inherently clear if the code will necessarily do what it says it does. That seems questionable for something as important as a kernel and driver.
2. Only one real Rust compiler, that's a recursive compiler, which reminds me of the Trusting Trust problem: https://dl.acm.org/doi/abs/10.1145/358198.358210
> 1. It doesn't map almost 1:1 to assembly the way C does, so it's not inherently clear if the code will necessarily do what it says it does.
As someone who works on a C compiler, I will tell you that Rust maps marginally better 1:1 to assembly than C does. No major C compiler goes 1:1 to assembly; it all gets flushed into a compiler IR that happily mangles the code in fun and interesting ways before getting compiled into the assembly you get at the end. Rust code does that too, but at least Rust doesn't pull anything silly on you like the automatic type promotion that C does.
If C maps 1:1 to assembly in your view, then (unsafe) Rust does; if Rust doesn't map 1:1 to assembly, nor does C. It's as simple as that.
1. C doesn’t actually do that. Rust is the same as C in this regard.
2. The Linux kernel doesn’t use standard C, it uses many gcc specific extensions. By this point, clang also supports those extensions and can compile the kernel, but that took work, and upstream has never tried to be only standard C.
As a side note, does anyone know what the backup plan is if Linus is suddenly no longer able to lead in his current capacity? I think it's likely there is one, but am not sure what it is.
In a previous interview (several years ago) Linus said "there are at least a dozen people who can take over tomorrow if I get hit by a bus", or something to that effect. I don't think there's a specific concrete plan.
Realistically, what will probably happen is that all the core maintainers will end up in a big room and discuss what to do next. Maybe they will do something with white smoke from a chimney. It's also very possible the nature of the leadership will change, rather than a simple s/Linus/…/.
ATM Greg KH would probably take over (since he's already done it once before). I doubt he's the last in the line of succession though
No, but as long as it doesn't land in Microsoft's hands I'm happy. edit: Not Oracle either
Does Rust support the same range of architectures as C? Or is there some way to compile Rust to C to support weird obscure systems?
Forgive me if this is something commonly known by the people involved. It just strikes me as the most obvious objection to Rust in the kernel and I haven't seen any explanation of what's going to happen.
Currently Rust is only acceptable in drivers. These are inherently platform specific, so there’s no issue with platform support. If Rust doesn’t support the platform, the driver won’t be written in it.
Rust’s platform support is better than you might assume, but it is missing some platforms the kernel itself supports, so until that’s resolved, it can’t be in the core of things.
Check out the Rust's documentation page on platform support[0]. You'll be able to find the full list of supported platforms, as well as the target tier policy, and specific target requirements and maintainers.
Rustc lowers to LLVM IR, so it can target anything LLVM can. For a long while, that meant there were obscure architectures that were excluded, but IIRC coverage has improved and the Linux kernel has decided to drop support for them.
The main push has actually been from the BSD family pushing clang (and thus LLVM) to support a broader swath of less common architectures.
rustc does not yet no, there's a lot of hope in the gcc rust frontend to help bridge the gap, but also there is increasing support in llvm for more architectures and things like this should drive interest in accelerating those projects.
rust doesn't support alpha, parisc, or super-h, but afaict there are at least nominally functional back ends for the other platforms modern linux runs on
What is the value in relying on distro authors to publish rust compiler versions, when the bespoke release channel for rustc is kept much more up to date?
How can you build a new kernel with distro tools otherwise?
With rustup? Why do you need the distro to be the be and end all of package management when it's more concerned with user space and not real development?
I think the point is that maybe you shouldn't. (i'm not agreeing or disagreeing with that position).
If you used a distro that provided multiple versions of something and kept them up to date or used nix or guix you wouldn't have this problem at all.
Why can't all symbols exported to modules maintain a C ABI, obviating (if I understand correctly) the genksyms problem?
Because then when you want to write a module in Rust, all your interfacing with the rest of the kernel will be done through C function calls, with C semantics, and C expectations of ownership. There's really little point to adding Rust abstractions to the kernel, then, at least when it comes to modules.
But without a stable ABI can you expect modules to realistically work across versions? It seems like a similar problem to shared libraries, which rust punts on.
The kernel doesn't offer a stabke ABI for modules regardless of Rust. So what you're describing is already the case.
Sure, it changes when something changes, but with rust it changes (in theory) without any code changes but with a tool chain change.
The point is that there’s no requirement at all, so the rate of change is irrelevant.
I’ve read many times that a goal is to see if the use of Rust can work out in the kernel.
What does this experiment for? What exactly is the evaluation? What are some example findings, both pro and con?
With the Rust team falling apart, who is actually long term going to maintain it? I want to use it but I just see drama.
Not sure I'd agree they are falling apart but just to be clear, I think you're referring to the rust Linux team, not the actual rust language team, right?
Who says the Rust team is falling apart?
The project lead left after being admonished by Theodore T'so
The RfL project lead is Miguel Ojeda. He hasn’t gone anywhere.
I think that was the lead for the group getting RUST in the kernel.
RUST itself is still strong outside of the kernel.
One person left. "Falling apart" is a bit hyperbolic, no?
The Rust team is not "falling apart". The article specifically says it's not. One person left. Many people leave projects for many different reasons.
Same thing will happen as happened when OpenBSD team fell apart.
Not sure why the downvoting. It’s a serious question. Who is ensuring that this project has a future and isn’t going to collapse tomorrow?
Asserting that a team is collapsing with no evidence will get downvotes.
This work is funded by Google and I believe others. So that’s a positive signal towards maintainability. Regardless of a specific person being involved or not, Google has significant Rust components in Android and a vested interest in all this.
But also on some level, it’s too early for these questions. Stuff is still an experiment. It could all get removed tomorrow. Once it’s closer to being permanent, then “how do we continue to maintain this” becomes a more important question.
Google funding is a positive signal?
This link is about consumer products, not about technical projects.
If you believe Android will be killed soon, sure. I do not.
Android sits at the heart of their mass surveillance network. Rust experiments in the kernel? Seems like quite a stretch between the two to me.
I'd find more comfort in the "others" that you mentioned, although I don't know who they are.
Saying Android is bad is irrelevant. It’s an important project for Google.
> Seems like quite a stretch
It’s not a stretch, they’ve been talking publicly about their increased Rust usage in Android (among others) for years now. Here’s a 2023 post for example https://security.googleblog.com/2023/10/bare-metal-rust-in-a...
I rolled my eyes but then I realize you self-replied and actually laughed out loud.
Maybe next time do a tiny bit of looking before asserting unsubstantiated statements and then doubling down calling your own unsubstantiated question "serious". Not a serious way to conduct discourse, just tossing that out there.
It's a loaded question, like "have your stopped beating your wife yet?"