Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in the kernel is no longer experimental

lwn.net

Post reply on HN
Print view View original

521–530 of 853 posts

Re: Rust in the kernel is no longer experimental

#521

Post by jacquesm »

hollerith wrote: post #511
jacquesm wrote: post #509

Earlier quoted context omitted.

Without a very hard commitment that is going to be a huge hurdle to continued adoption, and kernel work is really the one place where rust has an actual place. Everywhere else you are most likely better off using either Go or Java.

Aren't large parts of a web browser and a runtime for a programming language also better written in Rust than in Go or Java?

I'd say no, access to a larger pool of programmers is an important ingredient in the decision of what you want to write something in. Netscape pre-dated Java which is why it was written in C/C++ and that is why we have rust in the first place. But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available programmers. For Go the situation is a bit less good but if you really need that extra bit of performance (and you almost never really do) then it might be a good choice.

Re: Rust in the kernel is no longer experimental

#522

Post by agentultra »

weebull wrote: post #464
eru wrote: post #310

Earlier quoted context omitted.

I would be. Mostly because while Zig is better than C, it doesn't really provide all that much benefit, if you already have Rust.

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…

From a safety perspective there isn't a huge benefit to choosing Zig over C with the caveat, as others have pointed out, that you need to enable more tooling in C to get to a comparable level. You should be using -Wall and -fsanitize=address among others in your debug builds.

You do get some creature comforts like slices (fat pointers) and defer (goto replacement). But you also get forced to write a lot of explicit conversions (I personally think this is a good thing).

The C interop is good but the compiler is doing a lot of work under the hood for you to make it happen. And if you export Zig code to C... well you're restricted by the ABI so you end up writing C-in-Zig which you may as well be writing C.

It might be an easier fit than Rust in terms of ergonomics for C developers, no doubt there.

But I think long-term things like the borrow checker could still prove useful for kernel code. Currently you have to specify invariants like that in a separate language from C, if at all, and it's difficult to verify. Bringing that into a language whose compiler can check it for you is very powerful. I wouldn't discount it.

Re: Rust in the kernel is no longer experimental

#524

Post by delamon »

dzaima wrote: post #342
eru wrote: post #306

Earlier quoted context omitted.

At least for a double linked list you can probably get pretty far in terms of performance in the non-intrusive case, if your compiler unboxes the contained item into your nodes? Or are there benefits left in intrusive data structures that this doesn't capture?

Storing the data in nodes doesn't work if the given structure may need to be in multiple linked lists, which iirc was a concern for the kernel? And generally I'd imagine it's quite a weird form for data structures for which being in a linked list isn't a core aspect (no clue what specifically the kernel uses, but I could imagine situations where where objects aren't in any linked list for 99% of time, but must be abl…

> Storing the data in nodes doesn't work if the given structure may need to be in multiple linked lists

That is why kernel mostly (always?) uses intrusive linked lists. They have no such problem.

Re: Rust in the kernel is no longer experimental

#526

Post by delamon »

wiz21c wrote: post #195
biorach wrote: post #145

Earlier quoted context omitted.

There are certain styles of programming and data structure implementations that end up requiring you to fight Rust at almost every step. Things like intrusive data structures, pointer manipulation and so on. Famously there is an entire book online on how to write a performant linked list in idiomatic Rust - something that is considered straightforward in C. For these cases you could always use Zig instead of C

it is not straightforward in rust because the linked list is inherently tricky to implement correctly. Rust makes that very apparent (and, yeah, a bit too apparent). I know, a linked list is not exactly super complex and rust makes that a bit tough. But the realisation one must have is this: building a linked list will break some key assumptions about memory safety, so trying to force that into rust is just not gonna…

Can you elaborate, what key assumptions about memory safety linked lists break? Sure, double linked lists may have non-trivial ownership, but that doesn't compromise safety.

Re: Rust in the kernel is no longer experimental

#527

Post by delamon »

eru wrote: post #306
ahartmetz wrote: post #241

Earlier quoted context omitted.

A container class that needs cooperation from the contained items, usually with special data fields. For example, a doubly linked list where the forward and back pointers are regular member variables of the contained items. Intrusive containers can avoid memory allocations (which can be a correctness issue in a kernel) and go well with C's lack of built-in container classes. They are somewhat common in C and very rar…

At least for a double linked list you can probably get pretty far in terms of performance in the non-intrusive case, if your compiler unboxes the contained item into your nodes? Or are there benefits left in intrusive data structures that this doesn't capture?

> if your compiler unboxes the contained item into your nodes

Is there known compilers that can do that?

Re: Rust in the kernel is no longer experimental

#528

Post by stackedinserter »

Why do Rust developers create so much drama everywhere? "Rewrite everything to Rust", "Rust is better than X" in all threads related to other languages, "how do you know it's safe if you don't use Holy Glorious Rust".

I'm genuinely not trolling, and Rust is okay, but only Rust acolytes exhibit this behaviour.

Re: Rust in the kernel is no longer experimental

#529

Post by pta2002 »

embedding-shape wrote: post #420
pta2002 wrote: post #295

Earlier quoted context omitted.

A few distros already do that. Of the top of my head, both NixOS and Arch enable the QR code kernel panic screen, which is written in Rust. Granted, those are rather bleeding edge, but I know a few more traditional distros have that enabled (I _think_ fedora has it? But not sure).

> both NixOS and Arch enable the QR code kernel panic screen Interesting, I use both (NixOS on servers, Arch for desktop) and never seen that. Seems you're referring to this: https://rust-for-linux.com/drm-panic-qr-code-generator (which looks like this: https://github.com/kdj0c/panic_report/issues/1 ) Too bad NixOS and Arch is so stable I can't remember the last time any full system straight up panicked.

Yep, that's what I'm referring to.

For now there aren't many popular drivers that use Rust, but there are currently 3 in-development GPU drivers that use it, and I suspect that when those get merged that'll be the real point of no return:

- Asahi Linux's driver for Apple GPUs - https://rust-for-linux.com/apple-agx-gpu-driver

- The Nova GPU driver for NVIDIA GPUs - https://rust-for-linux.com/nova-gpu-driver

- The Tyr GPU driver for Arm Mali GPUs - https://rust-for-linux.com/tyr-gpu-driver

I suspect the first one of those to be actually used in production will be the Tyr driver, especially since Google's part of it and they'll probably want to deploy it on Android, but for the desktop (and server!) Linux use-case, the Nova driver is likely to be the major one.

Re: Rust in the kernel is no longer experimental

#530

Post by mainecoder »

Yossarrian22 wrote: post #458
linuxfax wrote: post #451

Earlier quoted context omitted.

He also said in that same email regarding Rust that: > nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so. So any argument that Rust would ever fully replace C in such a way that C would go away and be banned in the kernel is NOT what Linus said. https://lkml.org/lkml/2025/2/20/2066

That’s a reasonable position today, but what about in 20 years?

All I know is that RUST will lose skill issue and C will win
Post reply on HN