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

491–500 of 853 posts

Re: Rust in the kernel is no longer experimental

#491

Post by acdha »

muvlon wrote: post #425
bmicraft wrote: post #292

Earlier quoted context omitted.

Which ones would that be?

In order to figure this out I took the list of platforms supported by Rust from https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and those supported by Linux from https://docs.kernel.org/arch/index.html , cleaned them up so they can be compared like for like and then put them into this python script: linux = { "alpha", "arc", "arm", "aarch64", "csky", "hexagon", "loongarch", "m68k", "microblaze", "mips…

It’s an interesting list from the perspective of what kind of project Linux is. Things like PA-RISC and Alpha were dead even in the 90s (thanks to the successful Itanium marketing push convincing executives not to invest in their own architectures), and SuperH was only relevant in the 90s due to the Dreamcast pushing volume. That creates an interesting dynamic where Linux as a hobbyist OS has people who want to support those architectures, but Linux as the dominant server and mobile OS doesn’t want to hold back 99.999999+% of the running kernels in the world.

Re: Rust in the kernel is no longer experimental

#492

Post by bigfishrunning »

semiinfinitely wrote: post #93

This is great because it means someday (possibly soon) Linux development will slowly grind to a halt and become unmaintainable, so we can start from scratch and write a new kernel.

You can start from scratch and write a new kernel now! Nothing's stopping you.

Re: Rust in the kernel is no longer experimental

#494

Post by ACCount37 »

pornel wrote: post #332
ACCount37 wrote: post #211

Earlier quoted context omitted.

There's a "point of no return" when you start to struggle to hire anyone on your teams because no one knows the language and no one is willing to learn. But C++ is very far from it.

There's always someone willing to write COBOL for the right premium. I'm working on Rust projects, so I may have incomplete picture, but I'm from what I see when devs have a choice, they prefer working with Rust over C++ (if not due to the language, at least due to the build tooling).

Writing C++ is easier than writing Rust. But writing safe multithreaded code in C++?

I don't want to write multithreaded C++ at all unless I explicitly want a new hole in my foot. Rust I barely have any experience with, but it might be less frustrating than that.

Re: Rust in the kernel is no longer experimental

#495

Post by viraptor »

weebull wrote: post #455
ramon156 wrote: post #353

Earlier quoted context omitted.

Rightfully so, its probably the place where you'll het most ROI

I don't understand why. Working with hardware you're going to have to do various things with `unsafe`. Interfacing to C (the rest of the kernel) you'll have to be using `unsafe`. In my mind, the reasoning for rust in this situation seems flawed.

The amount of unsafe is pretty small and limited to where the interfacing with io or relevant stuff is actually happening. For example (random selection) https://lkml.org/lkml/2023/3/7/764 has a few unsafes, but either: a) trivial structure access, or b) documented regarding why it's valid. The rest of the code still benefits.

But that's not the only reason Rust is useful - see the end of the write-up from the module author https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ ("Rust is magical!" section)

Re: Rust in the kernel is no longer experimental

#496

Post by Lariscus »

amiga386 wrote: post #426
bmicraft wrote: post #292

Earlier quoted context omitted.

Which ones would that be?

https://lwn.net/Articles/1045363/ > Rust, which has been cited as a cause for concern around ensuring continuing support for old architectures, supports 14 of the kernel's 20-ish architectures, the exceptions being Alpha, Nios II, OpenRISC, PARISC, and SuperH.

Its strange to me that Linux dropped Itanium two years ago but they decided to keep supporting Alpha and PA-RISC.

Re: Rust in the kernel is no longer experimental

#497

Post by phyzome »

weebull wrote: post #455
ramon156 wrote: post #353

Earlier quoted context omitted.

Rightfully so, its probably the place where you'll het most ROI

I don't understand why. Working with hardware you're going to have to do various things with `unsafe`. Interfacing to C (the rest of the kernel) you'll have to be using `unsafe`. In my mind, the reasoning for rust in this situation seems flawed.

The point is that lots of the code won't be `unsafe`, and therefore you benefit from memory safety in those parts.

Re: Rust in the kernel is no longer experimental

#498

Post by bigfishrunning »

Surac wrote: post #186

[flagged]

You should learn some, you might change your opinion! At the end of the day, having some pressure to select for kernel developers that are open minded and willing to learn new things might not be a bad thing. And at any rate, C will be a big part of kernel development forever, so those unwilling to learn new tools or techniques can still contribute in a meaningful way if they want to.

Re: Rust in the kernel is no longer experimental

#499

Post by viraptor »

josephg wrote: post #407
johncolanduoni wrote: post #283

Earlier quoted context omitted.

Drivers are interesting from a safety perspective, because on systems without an IOMMU sending the wrong command to devices can potentially overwrite most of RAM. For example, if the safe wrappers let you write arbitrary data to a PCIe network card’s registers you could retarget a receive queue to the middle of a kernel memory page.

> if the safe wrappers let you write arbitrary data to a PCIe network card’s registers Functions like that can and should be marked unsafe in rust. The unsafe keyword in rust is used both to say “I want this block to have access to unsafe rust’s power” and to mark a function as being only callable from an unsafe context. This sounds like a perfect use for the latter.

> Functions like that can and should be marked unsafe in rust.

That's not how it works. You don't mark them unsafe unless it's actually required for some reason. And even then, you can limit that scope to a line or two in majority of cases. You mark blocks unsafe if you have to access raw memory and there's no way around it.

Re: Rust in the kernel is no longer experimental

#500

Post by viraptor »

weebull wrote: post #456
josephg wrote: post #407

Earlier quoted context omitted.

> if the safe wrappers let you write arbitrary data to a PCIe network card’s registers Functions like that can and should be marked unsafe in rust. The unsafe keyword in rust is used both to say “I want this block to have access to unsafe rust’s power” and to mark a function as being only callable from an unsafe context. This sounds like a perfect use for the latter.

So if you're writing a device driver in rust... - Hardware access is unsafe - Kernel interface is unsafe How much remains in the layer in-between that's actually safe?

All logic, all state management, all per-device state machines, all command parsing and translation, all data queues, etc. Look at the examples people posted in other comments.
Post reply on HN