Earlier quoted context omitted.
Perhaps we can finally stop defining abis in terms of c structs!
If only Rust had a spec to do that with
It's being worked on! https://github.com/rust-lang/rfcs/pull/3470
Rust in the kernel is no longer experimental
821–830 of 853 posts
Re: Rust in the kernel is no longer experimental
#822Earlier quoted context omitted.
In normal user-mode rust, not running inside the kernel at all, you can open /dev/mem and write whatever you want to any process's memory (assuming you are root). This does not require "unsafe" at all. Another thing you can do from rust without "unsafe": output some buggy source code that invokes UB in a language like C to a file, then shell out to the compiler to compile that file and run it.
Sure, but those are non-central to what the program is doing. Writing to the wrong register offset and hosing main memory is a thing that happens when developing drivers (though usually it breaks obviously during testing).
Right, you're not wrong that this is a possible failure mode which Rust's guarantees don't prevent.
I'm just pointing out that "your program manipulates the external system in such a way that UB is caused" is outside the scope of Rust's guarantees, and kernel development doesn't fundamentally change that (even though it might make it easier to trigger). Rust's guarantees are only about what the Rust code does; anything else would be hard or impossible to guarantee and Rust doesn't try to do so.
Re: Rust in the kernel is no longer experimental
#823Earlier quoted context omitted.
It's not that it cannot, it just doesn't want to :-) (but you're right). I guess that in this very case of DLL, it's a bit hard to swallow. To be honest, it's because the rest of rust really helps me in other areas of my projects that I have accepted that. Learning the ownership model of rust is really painful, it really forces you to code in its way and it was not pleasant to me.
I've been trying to convert to Rust an in-memory database and failed. It is strictly single-threaded and full of intrusive lists. I tried hard to please borrow-checker, but one have little choice when internal structures are full of cycles. The result was ugly mess of Rc all over the place. I guess it is just an example of a problem that doesn't fit Rust well. This makes me wonder: what performance cost Rust code pay…
Using Rc doesn't sound like an intrusive list to me. Personally I find tons of Rcs to be messy, so I'd agree with you.
> what performance cost Rust code pay due to inability represent cyclic structures efficiently?
You can still write the code you'd write in C with unsafe. There's no inherent loss left on the table.
Furthermore, a lot of C folks reach for intrusive lists because it's easy in C, but that doesn't mean that it's always the most performant. See https://bcantrill.dtrace.org/2018/09/28/the-relative-perform... as an example of this phenomenon.
Re: Rust in the kernel is no longer experimental
#824Earlier quoted context omitted.
>> Yes, you can use it everywhere. Is that what you consider a success? > ... yes? Then perhaps you and I define success differently? As I've said in other comments above, C persisting or really standing still is not what I would think of as a winning and vibrant community. And the moving embedded and kernel development from what was previously a monoculture to something more diverse could be a big win for developers…
Sometimes it's nice to know that something will run and compile reliably far into the future. That's a nice thing to have, and wide support for the language and its relatively unchanging nature make it reliable.
> Sometimes it's nice to know that something will run and compile reliably far into the future.
I'm not sure why you think this is a problem that Rust has? Perhaps you mean something different but the Rust project compiles available code on crate.io upon the release of a new version.[0] C compilers may imagine their new compiler code doesn't break old software, but Rust takes that extra step, so we know it won't.
Now, the Rust kernel is currently using beta and nightly features which are on track for inclusion in the stable Rust compiler. So, yes, right now compilation is tied to a specific kernel version, and may need to be updated if a feature changes. However, any C compiler used to compile the Linux kernel uses non-standard GCC extensions only recently adopted by clang. Imagine if the C standards committee chose to change the syntax/sematics of a non-standard extension. Do you not imagine the non-standard extension would also be similarly deprecated?
The issue seems to be Rust is telling you what is non-standard, and you're yelling "Look it's non-standard!". But consider that the kernel in practice is using lots of non-standard features, and should the C standard simply adopt this non-standard behavior that means likely having to changes lots of code.
Re: Rust in the kernel is no longer experimental
#825Earlier quoted context omitted.
> Not optimal for ease of compilation and building old versions of the Kernel. (You need a specific version of the nightly compiler to build a specific version of the Kernel) It's trivial to install a specific version of the toolchain though.
You don't generally need specific versions of GCC or Clang to build it I'm pretty sure.
> You don't generally need specific versions of GCC or Clang to build it I'm pretty sure.
You need a C11 compiler these days with loads of non-standard extensions. Note, for a very long time, one couldn't compile the Linux kernel with clang because it lacked this GCC specific behavior.
I'm not really sure you can turn around and say -- Oh, but now we feel differently about the C standard -- given how much is still non-standard. For instance, I don't believe Intel's C compiler will compile the kernel, etc.
Re: Rust in the kernel is no longer experimental
#826Earlier quoted context omitted.
I personally feel the Zig is a much better fit to the kernel. It's C interoperability is far better than Rust's, it has a lower barrier to entry for existing C devs and it doesn't have the constraints the Rust does. All whilst still bringing a lot of the advantages. ...to the extent I could see it pushing Rust out of the kernel in the long run. Rust feels like a sledgehammer to me where the kernel is concerned. It's…
I’m not so sure. The big selling point for Rust is making memory management safe without significant overhead. Zig, for all its ergonomic benefits, doesn’t make memory management safe like Rust does. I kind of doubt the Linux maintainers would want to introduce a third language to the codebase. And it seems unlikely they’d go through all the effort of porting safer Rust code into less safe Zig code just for ergonomic…
> Zig, for all its ergonomic benefits, doesn’t make memory management safe like Rust does.
Not like Rust does, no, but that's the point. It brings both non-nullable pointers and bounded pointers (slices). They solve a lot of problem by themselves. Tracking allocations is still a manual process, but with `defer` semantics there are many fewer foot guns.
> I kind of doubt the Linux maintainers would want to introduce a third language to the codebase.
The jump from 2 to 3 is smaller than the jump from 1 to 2, but I generally agree.
Re: Rust in the kernel is no longer experimental
#827Earlier quoted context omitted.
wasn't there like a drive by maintainer rejection of something rust related that kind of disrupted the asahi project ? i can't say i followed the developments much but i do recall it being some of that classic linux kernel on broadway theater. i also wonder if that was a first domino falling of sorts for asahi, i legitimately can't tell if that project lives on anymore
It involved large parts of the Rust community, and the famous Rust developer Hector Martin (with an alter ego of Asahi Lina, a female vtuber, which he appears irrationally embarrassed about), harassing others. Even Linus Torvalds called out Hector Martin. https://lkml.org/lkml/2025/2/6/1292 > On Thu, 6 Feb 2025 at 01:19, Hector Martin wrote: > > If shaming on social media does not work, then tell me what does, becaus…
Linus Torvalds rips into Hellwig for blocking Rust for Linux:
https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4d...
Re: Rust in the kernel is no longer experimental
#828After all the resistance to Rust in the Linux Kernel, it's finally official. Kudos to the Linux Rust team!
wasn't there like a drive by maintainer rejection of something rust related that kind of disrupted the asahi project ? i can't say i followed the developments much but i do recall it being some of that classic linux kernel on broadway theater. i also wonder if that was a first domino falling of sorts for asahi, i legitimately can't tell if that project lives on anymore
Yes.
Linus Torvalds rips into Hellwig for blocking Rust for Linux:
https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4d...
The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL.
It was literally just another user of it, in a completely separate subdirectory, that didn't change the code you maintain in _any_ way, shape, or form.
I find it distressing that you are complaining about new users of your code, and then you keep bringing up these kinds of complete garbage arguments.
Honestly, what you have been doing is basically saying "as a DMA maintainer I control what the DMA code is used for".
And that is not how *any* of this works.
Re: Rust in the kernel is no longer experimental
#829[flagged]
Re: Rust in the kernel is no longer experimental
#830[flagged]
Many of your comments seem to be charged meta-commentary about posts and threads. If you want to participate on HN, please do so as it's intended: by discussing the topics in a curious, conversational way. If other users are engaging in ideological battle, they are breaking the guidelines and you are welcome to flag their comments and email us (hn@ycombinator.com) to report them. If a post is bad for HN, you can flag it and email us explaining why. We can and do routinely take action against abuse or manipulation on HN when we know about it. But this kind of "something needs to be done" proclamation, without any engagement with the moderators or actionable suggestions, amounts to nothing more than empty venting, which can only drag this place downwards.
Please make an effort to observe the guidelines if you want to participate here.