Comment by dcrazy
2 months ago
Does the removal of “experimental” now mean that all maintainers are now obligated to not break Rust code?
2 months ago
Does the removal of “experimental” now mean that all maintainers are now obligated to not break Rust code?
I believe the removal of the "experimental" nomenclature is just an indication that Rust is "here to stay" in the kernel (which essentially means that developers can have confidence investing in writing Rust based drivers).
The overall rules haven't changed.
Strictly speaking they've always been obligated to not break the Rust code, but the R4L developers have agreed to fix it on some subsystems behalf IIRC so Rust can be broken in the individual subsystem trees. But I think it's been the case all along that you can't send it to Linus if it breaks the Rust build, and you probably shouldn't send it to linux-next either.
Yeah I was wondering about that one angry bearded guy in that movie. He will be very upset.
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
3 replies →
linus torvalds
7 replies →
Is rust code part of user space?
This is the Linux kernel. User space can do whatever it wants.
That's a woosh moment
1 reply →
Projects like GNOME are increasingly using Rust.
From kernel side, I meant - I wasn't clear. Now I understand what's the meaning of "don't break rust code". Happy that rust's journey in the kernel is successful so far. The pace seems strong.
No maintainer is obligated to not break any part of Linux other than the user space API, there are no stable in-kernel APIs
What they mean is that the Linux kernel has a long-standing policy to keep the whole kernel compilable on every commit, so any commit that changes an internal API must also fix up _all_ the places where that internal API is used.
While Rust in the kernel was experimental, this rule was relaxed somewhat to avoid introducing a barrier for programmers who didn't know Rust, so their work could proceed unimpeded while the experiment ran. In other words, the Rust code was allowed to be temporarily broken while the Rust maintainers fixed up uses of APIs that were changed in C code.
So does this mean that the C developers might need to learn Rust or cooperate more with the rust developer team basically?
11 replies →
There is, I understand, an expectation that if you do make breaking changes to kernel APIs, you fix the callers of such APIs. Which has been a point of contention, that if a maintainer doesn't know Rust, how would they fix Rust users of an API?
The Rust for Linux folks have offered that they would fix up such changes, at least during the experimental period. I guess what this arrangement looks like long term will be discussed ~now.
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.
17 replies →