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

631–640 of 853 posts

Re: Rust in the kernel is no longer experimental

#631

Post by torginus »

jcranmer wrote: post #70
kbolino wrote: post #43

Earlier quoted context omitted.

I'm genuinely surprised that usize pointer convertibility exists. Even Go has different types for pointer-width integers (uintptr) and sizes of things (int/uint). I can only guess that Rust's choice was seen as a harmless simplification at the time. Is it something that can be fixed with editions? My guess is no, or at least not easily.

There is a cost to having multiple language-level types that represent the exact same set of values, as C has (and is really noticeable in C++). Rust made an early, fairly explicit decision that a) usize is a distinct fundamental type from the other types, and not merely a target-specific typedef, and b) not to introduce more types for things like uindex or uaddr or uptr, which are the same as usize on nearly every p…

I'd say, that even more than pointer sizes, the idea that a pointer is just a number really needs to die, and is in no way a forward looking decision expected of a modern language.

Pointers should at no point be converted into numbers and back as that trips up many assumptions (special runtimes, static/dynamic analysis tools, compiler optimizations).

Additionally, I would make it a priority that writing FFIs should be as easy as possible, and requires as little human deliberation as possible. Even if Rust is safe, its safety can only be assumed as long as the underlying external code upholds the invariants.

Which is a huge risk factor for Rust, especially in today's context of the Linux kernel. If I have an object created/handled by external native code, how do I make sure that it respects Rust's lifetime/aliasing rules?

What's the exact list of rules my C code must conform to?

Are there any static analysis/fuzzing tools that can verify that my code is indeed compliant?

Re: Rust in the kernel is no longer experimental

#632

Post by kaoD »

menaerus wrote: post #623
kaoD wrote: post #531

Earlier quoted context omitted.

How is that worse than everything being unsafe? I've seen this argument thrown around often here in HN ( "$IMPROVEMENT is still not perfect! So let's keep the statu quo." ) and it baffles me. C is not perfect and it still replaced ASM in 99% of its use cases.

No, I am not saying keep the status quo. I am simply challenging the idea that kernel will enjoy benefits that is supposed to be provided by Rust. Distribution of bugs across the whole codebase is not following the normal distribution but multimodal. Now, imagine where the highest concentration of bugs will be. And how many bugs there will be elsewhere. Easy to guess.

> Now, imagine where the highest concentration of bugs will be. And how many bugs there will be elsewhere.

You're doing it again!

Doesn't matter where the majority of bugs will be. If you avoid the minority it's still an improvement.

Also, Rust safety is not related at all to bugs. You seem to have a misunderstanding of what Rust is or what safe Rust provides.

(Also, I'd challenge the rest of your assumptions, but that's another story.)

Re: Rust in the kernel is no longer experimental

#633

Post by torginus »

accelbred wrote: post #628
QuiEgo wrote: post #68

Earlier quoted context omitted.

Rust still compiles into bigger binary sizes than C, by a small amount. Although it’s such a complex thing depending on your code that it really depends case-by-case, and you can get pretty close. On embedded systems with small amounts of ram (think on the order of 64kbytes), a few extra kb still hurts a lot.

Lack of stable build-std and panic_immediate_abort features result in a order of magnitude size difference for some rust code I have. Using no_std brings it to ~60kb from ~350kb, but still more than the ~40kb for the C version

Afaik despite Rust not having exceptions, panic still unwinds the stack and executes 'drop'-s the same way C++ does, which means the code retains much of the machinery necessary to support exceptions.

Re: Rust in the kernel is no longer experimental

#634

Post by estebank »

johncolanduoni wrote: post #244
jenadine wrote: post #183

And yet, the Linux kernel's Rust code uses unstable features only available on a nightly compiler. 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)

What if I told you… there was a simple, constant environment variable you could set to make the stable compiler forget it isn’t a nightly?

When it comes to nightly features use, it is good to note that a stable compiler, a nightly corresponding to the date beta for that stable was branched out and an arbitrary nightly are different. A branched-off nightly might have had beta back ports for fixing stable features that the nightly will not have, and a nightly feature that is subtly broken on stable but isn't used in std will not have received a backport. So using nightly feature on stable might mean every now and then skipping a stable version, and using a nightly compiler means having to do thorough testing after updating on arbitrary days. Any given nightly has high chances of being fine, but every update brings the possibility of bugs.

Re: Rust in the kernel is no longer experimental

#635

Post by xphos »

teekert wrote: post #459
grimgrin wrote: post #432

Earlier quoted context omitted.

linus torvalds

I can't find the movie, but there was a guy angry that stated that he should not have to learn Rust, nobody should. And Rust should not be in the kernel.

Its in a talk about File systems in Rust for Linux. Basically the rust maintainer who I think stepped down was talking about how the C-code base for VFS has a lot of documented but complex orderings where you have to call a lock, or pin before accessing an Inode(or something) one way but not the other. They made a bunch of Rust Types so you basically could not produce an illegal ordering and got heckled pretty hard by the "bearded guy". They basically run out the presentation time with heckling and I think the Rust maintainer quit a few months later (over many similar instances of this. don't quote me time line here)

[source] https://www.youtube.com/watch?v=WiPp9YEBV0Q

Re: Rust in the kernel is no longer experimental

#636

Post by torginus »

goku12 wrote: post #177
QuiEgo wrote: post #72

Earlier quoted context omitted.

Apple handled this problem by adding memory safety to C (Firebloom). It seems unlikely they would throw away that investment and move to Rust. I’m sure lots of other companies don’t want to throw away their existing code, and when they write new code there will always be a desire to draw on prior art.

That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the most, because they arguably have massive C codebases. Yet, they're also some of the most enthusiastic adopters and promoters of Rust. A lot of other adopters also have legacy C codebases. I'm not trying to hype up Rust or disparage C. I learned C first and then R…

I'm curious why your perspective on Rust as a HW engineer. Hardware does a ton of things - DMA, interrupts, etc. that are not really compatible with Rust's memory model - after all Rust's immutable borrows should guarantee the values you are reading are not aliased by writers and should be staying constant as long as the borrow exists.

This is obviously not true when the CPU can either yank away the execution to a different part of the program, or some foreign entity can overwrite your memory.

Additionally, in low-level embedded systems, the existence of malloc is not a given, yet Rust seems to assume you can dynamically allocate memory with a stateless allocator.

Re: Rust in the kernel is no longer experimental

#637

Post by bonzini »

mewse-hn wrote: post #583
bpavuk wrote: post #340

Earlier quoted context omitted.

I am missing some context, did not follow the Linux/Rust drama. which guy?

Ted T'so: "Here’s the thing: you’re not going to force all of us to learn Rust." https://arstechnica.com/gadgets/2024/09/rust-in-linux-lead-r... https://youtu.be/WiPp9YEBV0Q?t=1529

That was way way blown out of proportion. https://lwn.net/Articles/991062/ has a much less somber quote from just three months later:

> Ted Ts'o said that the Rust developers have been trying to avoid scaring kernel maintainers, and have been saying that "all you need is to learn a little Rust". But a little Rust is not enough to understand filesystem abstractions, which have to deal with that subsystem's complex locking rules. There is a need for documentation and tutorials on how to write filesystem code in idiomatic Rust. He said that he has a lot to learn; he is willing to do that, but needs help on what to learn

Re: Rust in the kernel is no longer experimental

#638

Post by ivell »

zozbot234 wrote: post #599
School-Cotton wrote: post #585

Earlier quoted context omitted.

> which has all of the rust safety guarantees and then some That's not really true. Data races are possible in Java.

Data races are possible on some types, specifically `long` when not declared as `volatile` - but these do not directly cause memory unsafety.

Not just some types - any object with members. Shared references are a thing in Java and if not careful can cause data races left and right.

Rust controls that quite a bit.

Re: Rust in the kernel is no longer experimental

#639

Post by QuiEgo »

goku12 wrote: post #177
QuiEgo wrote: post #72

Earlier quoted context omitted.

Apple handled this problem by adding memory safety to C (Firebloom). It seems unlikely they would throw away that investment and move to Rust. I’m sure lots of other companies don’t want to throw away their existing code, and when they write new code there will always be a desire to draw on prior art.

That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the most, because they arguably have massive C codebases. Yet, they're also some of the most enthusiastic adopters and promoters of Rust. A lot of other adopters also have legacy C codebases. I'm not trying to hype up Rust or disparage C. I learned C first and then R…

Not trying to make a value judgement on Rust either, just brainstorming why Rust changeover might go slow per the question.

FWIW I work in firmware with the heap turned off. I’ve worked on projects in both C and Rust, and agree Rust still adds useful checks (at the cost of compile times and binary sizes). It seems worth the trade off for most projects.

Re: Rust in the kernel is no longer experimental

#640

Post by menaerus »

kaoD wrote: post #632
menaerus wrote: post #623

Earlier quoted context omitted.

No, I am not saying keep the status quo. I am simply challenging the idea that kernel will enjoy benefits that is supposed to be provided by Rust. Distribution of bugs across the whole codebase is not following the normal distribution but multimodal. Now, imagine where the highest concentration of bugs will be. And how many bugs there will be elsewhere. Easy to guess.

> Now, imagine where the highest concentration of bugs will be. And how many bugs there will be elsewhere. You're doing it again ! Doesn't matter where the majority of bugs will be. If you avoid the minority it's still an improvement . Also, Rust safety is not related at all to bugs . You seem to have a misunderstanding of what Rust is or what safe Rust provides. (Also, I'd challenge the rest of your assumptions, but…

What am I exactly doing again? I am providing my reasoning, sorry if that itches you the wrong way. I guess you don't have to agree but let me express my view, ok? My view is not extremist or polarized as you see. I see the benefit of Rust but I say the benefit is not what Internet cargo-cult programming suggests. There's always a price to be paid, and in case of kernel development I think it outweighs the positive sides.

If I spend 90% of time debugging freaking difficult to debug issues, and Rust solves the other 10% for me, then I don't see it as a good bargain. I need to learn a completely new language, surround myself with a team which is also not hesitant to learn it, and all that under assumption that it won't make some other aspects of development worse. And for surely it will.

Post reply on HN