Rust For Linux Kernel Patches Revised With Upgraded Rust Toolchain, Build Improvements

[muncrief]

Have you actually heard of backwards compatibility?

I'm 62 mdedetrich

And have seen obvious disasters come and go.

So yes, I have not only heard of backwards compatibility, but witnessed the world suffering from the lack of it.

[betty567]

Rust is a completely unproven language, it is bonkers to consider it for inclusion into the Linux kernel. There is a serious lack of noteworthy applications written in Rust. Even C++ would be a saner choice for a 2nd language for "inclusivity" of people unable or unwilling to learn to use C at a high level. What's next, kernel Javascript? Porting parts of Firefox to Rust was the beginning of the end for Firefox and Mozilla, Firefox is in a downward spiral and they have been hemorrhaging market share ever since, because Rust did not bring all of the technical superiority their zealots claim that it should.

Evidence #1, Rust's own user showcase: https://www.rust-lang.org/production/users
A bunch of unheard of organizations. For the few that are noteworthy:
1. Ceph: Rust bindings for librbd. Yawn.
2. NPM: The fact that a critical infrastructure for a web framework/server cannot even eat their own dogfood at scale does not speak to their expertise in choosing Rust. Golang or Java would have been the safe choice.

Evidence #2: Random "big companies using Rust" articles, for example: https://serokell.io/blog/rust-companies
Almost all of these are huge companies that use dozens of languages internally, and they happen to have a few (at most) low-impact projects in Rust. Rust is not a top 10 language at any of these places.

Evidence #3: The "killer feature" of every open source project written in Rust is that it is written in Rust.
Rust is not enabling any next level capabilities, none of these apps are dominating anything. Even the OS kernel written in Rust has a bunch of "won't fix" critical security vulnerabilities stemming from the fact that Rust lacks the low-level capabilities of C. So much for the idiot-proof security of Rust.

[mdedetrich]

I'm 62 mdedetrich

And have seen obvious disasters come and go.

So yes, I have not only heard of backwards compatibility, but witnessed the world suffering from the lack of it.

So you are spreading FUD about Rust which is worse.

[stargeizer]

Languages like Rust and Python are unstable moving targets that will never be suitable for critical platforms or programs.

I mean seriously, just reading this article with the Rust developer calmly explaining that it was "simply" a matter of Rust being unstable, but this one part would be stable soon, made my head spin so hard I lost touch with reality for a few milliseconds.

My goodness, these fly-by-night languages don't even pretend to care about stability or backwards compatibility. They just come out with a version, realize there could be improvements, then chuck that version out the window and create a new, completely incompatible, one.

That's the opposite of progress.

It's chaos.

Don't mix Python (interpreted language) with Rust (Compilled language). Both have it's uses and caters to different paradigms and use-cases.(Altough i do agree with you about madness in Python case)

Rust is probably one of the quite few cases of design by comitee that works, actually. Probably because the guys behind it are mostly "sane people". So the Rust API is expected to be sane and stable, but NOT STATIC, quite akin to the Linux kernel itself in the userspace API.

Do you remember B.A.S.I.C.??. I mean seriuolsy. Even if that language was one of the most sanest (although, interpreted, and slow) at it's time, there were hundreds of "dialects" with theit own differences and every manufacturer took the microsoft code and then adapted to their magnificent 8-bit machines that sell at the time. Nowadays just look at the modern languages and compare with Rust. All of them loses in the "stable" department.

Yeah, i do agree Rust has its shortcomings, and is not for everyone, but even with that, is the best candidate nowadays for a second development language in the Linux Kernel, it's advantages clearly outweights any criticism, and is a good thing. But now it's usefullness have to be demoe'd to the kernel developers, and i think at least Christoph will oppose to it until the very first serious device driver written in Rust can surpass in quality, speed and safety to a C based device driver. (At least Linus Torvalds and Greg KH are more open to the idea.)

[Vistaus]

I live in the Netherlands.

Me too.

I wouldn't say that that ministry is well known for their good decision making.

I agree that none of our ministries know how to make good decisions, but that doesn't take away the fact that Python *is* used in a critical environment (Dutch government). Whether that's a good thing or not is a different subject.

[soulsource]

Looking forward to this. Rust currently is the best in class programming language, although Zig seems interessting aswell. The borrow checker is such a game changer. Since I started developing in Rust, I rarely have to use a debugger or google weird compiler messages and it helps writing better cpp code too.

This, so much.
For our current projects we are stuck with C++, but we are currently implementing helper functions for C++ that are heavily inspired by Rust's Iterators and Optionals. (You could also say: heavily inspired by functional programming, but in our case the direct inspiration is Rust.) When using those, you can directly feel the code quality improve. It will never reach the code quality of Rust code, simply because C++ has to be backwards compatible to language versions that were designed with the only goal being that compilation doesn't take long, but it's definitely a huge improvement over our previous coding style. That's mainly because you get forced to handle the "else" case for conditionals, and you start to think about data and transformations.

[Jabberwocky]

Compared to its early days, it's very, very stable at the moment. Additions to the language itself are focused things. Standard libraries are also pretty stable as a consequence. And a lot of works goes into the compiler and cargo. Hell, some things were fixed in LLVM because of Rust.

In fact, the last major addition to the language, afair, is async/await, two years ago.

jacob bug77 or anyone who is not trolling... Honest question here.

What's the difference in API vs ABI relative to Rust in a kernel and userland environment and does ABI stability impact the robustness of dynamic linking?

Here's what I understand from reading a few minutes yesterday – Rust does have a stable API which is admirable for it's age. Rust does not have a stable ABI and the devs are not planning to target one at this point in time. I understand that this is also something that changes in c/c++ depending on the implementation, still there's a big difference between targeting something and not supporting it altogether. Why would the Rust developers not target a stable ABI?

From my understanding ABI stability is a bigger issue for userland and dynamic linking. I do not see is how this impacts the kernel. One vendor compile a kernel module with Rust version X and another kernel module only supported Rust version Y but there's already a conflict between kernel versions anyway so it's not such a big issue IMO. Is that really the worst case impact regarding ABI stability (in the kernel) or is it possible for syscalls to be impacted by this too?

Another potential concern – I have seen people compare Rust to c++ based on features. Could Rust be used in a way that c++ would have been used in the kernel (making the no c++ rule irrelevant)? Is this a legitimate concern that could be mitigated by good code review or is it a bad comparison?

Yet another potential concern – Would using Rust make the kernel less portable AKA raise the bar of entry for experimental or educational processors?

PS: I think Rust in the kernel is a good thing. I'm curious what the broader pros and cons are.

[Isedonde]

Yet another potential concern – Would using Rust make the kernel less portable AKA raise the bar of entry for experimental or educational processors?

I believe that's an issue. Rust currently has limited hardware support. There is some effort to make it work with GCC which might help with building for more obscure systems. But right now, rustc is based on LLVM only and if LLVM doesn't support your target platform, then you can't compile your rust code for the target platform.

That's probably another reason why the Rust kernel work focuses on device drivers right now. You don't need a device driver for your gaming mouse / whatever random hardware when working with an experimental or educational processor.

The other things you mention are non-issues for the Kernel, I guess. IIRC Linus doesn't like C++ because it's basically one huge footgun, which Rust is not. The Rust ABI is not stable, but you can mark functions to use the platform's C ABI (FFI). I'm not sure if they use that for Rust code in the Kernel or some other mechanism to make interfacing between Kernel C and Rust code work. The internal kernel API is not stable, as far as I know, so dealing with an unstable ABI internally shouldn't be too much of an issue. In any case, the syscalls should be entirely unaffected, as those interfaces will still be handled in C code for the foreseeable future.

[silmeth]

From my understanding ABI stability is a bigger issue for userland and dynamic linking. (…)

Basically whenever you need dynamic linking, you use C-compatibile ABI, you don’t need full Rust ABI to be stable for this, you use FFI which is stable in Rust (Rust can easily expose a C-like interface, as it can itself call C-API interface from external dynamic libraries). This way the dynamically linked module doesn’t need to be written in Rust, it can be written in anything that can interface with C ABI (C itself, C++, D, or even Python or Java through their ways of doing FFI, etc. etc.). You don’t get full Rust expressiveness in the dynamic ‘foreign’ API this way, but you do get dynamic linking.

Of course that means that whenever you create a type or function that is intended to be usable from a dynamically linked module, you have to provide an FFI wrapper for it for dynamic linking – but in the case of the kernel where all its interfaces are C, that’s not a issue.

There are some efforts to make a stable Rust ABI (expressing at least a subset of Rust APIs and its guarantees), but stuff like generics which are a compile-type thing are hard or impossible to do this way anyway (not to mention metaprogramming stuff like macros and procedural macros); see how C++ has no “stable ABI” for its templates, they’re compile-time-only; Swift works around this by different approach to generics, using their witness tables and runtime reflection instead of monomorphisation, they keep all the needed info at runtime – but that’s the kind of implicit runtime magic and overhead that Rust tries hard to avoid. So a hypothetical “Stable ABI Rust” used for dynamic linking will still not be as rich expressive a language as full statically linked Rust is.

EDIT: stable ABI also raises some questions about stability guarantees and versioning scheme: adding a private field to a struct is generally a backwards API-compatibile change, but it would break ABI (again, Swift magically works around it in runtime), so it’s also not obvious how such changes should be handled in an ABI-stable Rust.

[bug77]

jacob bug77 or anyone who is not trolling... Honest question here.

What's the difference in API vs ABI relative to Rust in a kernel and userland environment and does ABI stability impact the robustness of dynamic linking?

Here's what I understand from reading a few minutes yesterday – Rust does have a stable API which is admirable for it's age. Rust does not have a stable ABI and the devs are not planning to target one at this point in time. I understand that this is also something that changes in c/c++ depending on the implementation, still there's a big difference between targeting something and not supporting it altogether. Why would the Rust developers not target a stable ABI?

From my understanding ABI stability is a bigger issue for userland and dynamic linking. I do not see is how this impacts the kernel. One vendor compile a kernel module with Rust version X and another kernel module only supported Rust version Y but there's already a conflict between kernel versions anyway so it's not such a big issue IMO. Is that really the worst case impact regarding ABI stability (in the kernel) or is it possible for syscalls to be impacted by this too?

Another potential concern – I have seen people compare Rust to c++ based on features. Could Rust be used in a way that c++ would have been used in the kernel (making the no c++ rule irrelevant)? Is this a legitimate concern that could be mitigated by good code review or is it a bad comparison?

Yet another potential concern – Would using Rust make the kernel less portable AKA raise the bar of entry for experimental or educational processors?

PS: I think Rust in the kernel is a good thing. I'm curious what the broader pros and cons are.

I believe you are spot on. In addition, for the time being Rust is meant for kernel drivers, which quite different from "Rust in the kernel".

The concerns about stability and interoperability have already been addressed (by people more knowledgeable than us) when it was decided to give Rust the go-ahead. The conclusion was Rust can help people write better drivers. And depending on how it fares in this one area, it may be considered for other parts of the kernel. But there is no timeline for that.

For comparison, remember how Windows (mostly) got rid of the dreaded blue screen. Using telemetry, it became apparent most of the crashes were due to poor drivers. Building on that, a new driver model was devised to mitigate many of the problems observed. While I don't think Linux has a driver model problem, a language that helps people implement what they think they implement can and will rid us of a lot of bugs. Whether Rust ever moves past drivers is mostly irrelevant, imho.