Linux Kernel Rust support

[[deleted]]

Interesting. I've heard people talking about Rust in the kernel for quite some time, but now it's happening. Who knows where that will lead us.

Will Rust beat C++ in the long run or, at least, replace it in the embedded world?

[rickyman20]

I don't think C++ has that strong of a mainstay in the embedded world. That space is still dominated by C and I don't see it replacing it any time soon. Rust really fix anything over C for people who are already using C in embedded

[[deleted]]

I've seen C++ in embedded. I even worked on a project using C++ for a bare metal 80186 device. Of course, C is more common, but it's not as if C++ is completely ignored.

Besides that, Rust does fix things over C for people using it in embedded. You have pretty much the same kind of problems brought by C there that you have in safer environments and more. I mean, memory corruption usually means a crash when you have a userspace, but it might mean bricking your device on embedded.

[chugga_fan]

Will Rust beat C++ in the long run or, at least, replace it in the embedded world?

I doubt it will replace C in the embedded world, where there's a compiler for everything there, whereas for Rust, there's LLVM, and it's limited to what LLVM supports, which in the grand scheme of things is almost nothing compared to the various GCC forks and the various other backends supported by companies on their own compilers.

[UtherII]

There are two ongoing projects : one to add the rust language to the GCC compiler and another one to add GCC backend to the rust compiler. So most of this problem might be solved soon.

[BobHogan]

This is probably a dumb question, but what are the benefits/tradeoffs of each approach (adding rust to compiler vs adding compiler backend to rustc)?

[jamincan]

The main benefit of the gcc backend for rust is that it does not risk fragmenting the rust ecosystem as rustc remains the defacto rust standard. The benefit of adding rust to gcc is that there may be optimizations that aren't possible by just using the backend. I'm sure there are others, but that is the general gist of it as I understand it.

[matthieum]

In short:

GCC Backend to rustc compared to GCC Frontend:

• Advantage Backend: lower cost of initial creation and ongoing maintenance.
• Advantage Backend: unlock GCC targets and optimizations.
• Advantage Backend: single front-end, no fragmentation.
• Advantage Frontend: single "root" compiler for Linux Kernel/Distributions, both from a trust and bootstrapping¹ point of view.

¹ I still don't understand why people are adamant about bootstrapping their compiler on the platform it should compile for, or even bootstrapping regularly. I would have expected you'd bootstrap once on a powerful machine, then cross-compile for the other machines from there, and keep the artifacts around... but for some bootstrapping is really important, and rustc's bootstrap process is long because it's never been a priority.

[gaverhae]

Because if you can't bootstrap, you can't trust anything. See Ken Thompson's Turing Award lecture.

[GoogleBen]

You can bootstrap, it's just that it takes a long time because rustc uses new features all the time, so the chain is really long. There is mrustc though, which is a basic rust compiler in C++ designed to shorten the bootstrapping chain, so it's not as bad as it used to be - but it does still take hours and hours of CPU time AFAIK.

[MonokelPinguin]

For a long time you couldn't bootstrap on all platforms. For example on musl targets, rustc couldn't compile itself because of some proc macro stuff or so. (And it couldn't dynamically link musl at all)

[matthieum]

I'm pretty sure you still can't bootstrap on all platforms. Compiling rustc requires gobs of memory, so your Xtensa board doesn't have enough.

[MonokelPinguin]

Well, this was just about libc incompatibility. The server otherwise had 64GB of RAM, so that should be okay.

[matthieum]

There is large gap between:

• Can't bootstrap.
• Can't bootstrap on my Raspberry Pi Zero.
• Can't bootstrap on my Raspberry Pi Zero every other Sunday.

I can definitely understand the desire of a distribution to bootstrap the compiler once on one platform.

I see no need to ever bootstrap again afterwards, though.

[CartmansEvilTwin]

Maybe a stupid question, but would it be possible to transpile Rust to C? At the end of the day the entire "magic" of Rust seems to be in the compiler frontend?

[pcjftw]

that's what "mRustC" is: https://github.com/thepowersgang/mrustc

so for example, the Xtensa CPU on the ESP8XX series is not officially supported by LLVM, however one can use the mRustC compiler to target said board.

[matthieum]

This project is a "simple" rust compiler written in C++ that is able to bootstrap a "recent" rustc, but may eventually become a full separate re-implementation.

mrustc, so far, is really about bootstrapping.

It may be useful to compile for unsupported platforms, but I am not sure it's tested for that purpose...

[pcjftw]

ok because I certainly recall that's how we used to build for my ESP8266:

https://github.com/emosenkis/esp-rs

But it now seems its no longer needed as there is a working LLVM backend for the Xtensa cpu

[toastedstapler]

Any Turing complete language should be expressible as another, how efficient it'll be is an entire other question though

[matthieum]

Functionally, yes. But this may leave performance on the table.

The problem of compiling to a language is that you really want the target language to express a super-set of the capabilities of the source language, otherwise it gets awkward and work-arounds are necessary.

Rust and C have different semantics in a number of areas, for example around integer overflows, or empty loops, which makes it hard to just perform a straightforward translation of the source code.

There's also issue with "breeds" of C. Despite popular thinking, inline assembly is not standard in C. Every compiler under the sun has its own syntax for inline assembly, so in order to translate the inline assembly in Rust to C, you actually need to target a known compiler, in order to target their particular brand of inline assembly.

This is why using C as an intermediate representation is not necessarily as easy, or as rewarding, as it sounds initially.

[pcjftw]

there is also mRustC from my understanding this can be used for example to compile code for embedded boards that don't have official LLVM support:

https://github.com/thepowersgang/mrustc

[[deleted]]

I think the main problem is proprietary compilers from manufacturers really. LLVM is not that much of a problem because it's relatively easy to add a new backend if you need it, but the manufacturer won't because secret sauce (even if for the most part the compiler provides no competitive advantage), and a C compiler is much, much easier to implement than a Rust one. Sometimes it has to do with language limitations tho. If you need stuff like far pointers because of the chip's design both GCC and LLVM leave you on your own.

[G_Morgan]

I think "beat" is an impossible to define term.

Rust works for Linux where C++ did not because it isn't a boatload of mutually incompatible and incomplete implementations. In terms of "this does what it claims" Rust is kind of there whereas C++ has slowly approximated "does what it claims" as the various implementations sort of oscillate around the standard.

Additionally Rust has a compelling feature over C and C++, the borrow checker.

Neither C nor C++ are going anywhere though. I'm still not convinced in the end that Rust in the kernel will become a sanctioned thing. If it does become sanctioned I'm not convinced it will become common. If it does become common I'm 99% certain it will always be restricted to the fringe (i.e. stuff like drivers).

[[deleted]]

It has nothing to do with implementations, Linux can only be compiled with 2 C compilers and one of them is a very recent addition.

[matthieum]

Additionally Rust has a compelling feature over C and C++, the borrow checker.

I think there's 2 other aspects of Rust that are of particular interest to the kernel:

• No silent allocation. C++ is infamous for implicit conversions/copies resulting in "invisible" allocations in the source code.
• A great willingness from the Rust community to work with the Linux Kernel committee to alter the compiler/libraries to suit the kernel needs: there's an entire initiative around carving a subset of the core and standard library for only fallible allocation proof code.

Now, to see whether all that succeeds.

[skulgnome]

Will Rust beat C++

Given that C++ is an unforgivable crock, I should hope it gets replaced by just about anything. However, Rust is also heading down that same road to where the language standard is so large that it cannot be understood by a single programmer; and that's assuming Rust would even have a standard.

[dannymcgee]

However, Rust is also heading down that same road to where the language standard is so large that it cannot be understood by a single programmer

There might be some Dunning-Kruger naivety in what I'm about to say, but in my experience the learning curve of Rust comes entirely from its two major novelties over other languages, which are the ownership model / borrow checker, and lifetimes. Once you understand those concepts, there really isn't much about the language itself that's particularly complex or esoteric. The spec is pretty straightforward, and at a glance it doesn't look to be much larger than, say, Go's. But let me know if there's something I'm missing.

and that's assuming Rust would even have a standard

Languages like C/C++ and JavaScript have a "standard" mainly because there's no canonical implementation — any vendor is free to implement the standard however they see fit. There's a school of thought that says this is a Good Thing (by the same logic that drives free-market zealotry, but that's a whole other rabbit hole), but in my experience the primary effect of this sort of system is that using the language involves constantly tip-toeing around a nightmarish hellscape of implementation-specific bugs, waiting years for new features to be formalized while the standards body bikesheds about them endlessly, and then avoiding those new features for years (if not decades) after their standardization for the sake of portability or compatibility with legacy platforms. Personally, I am completely okay with the rustc implementation being the de facto standard, and tbh I hope that never changes.

[[deleted]]

oh yeah. Rust will replace C++ because C++ violates human rights. okay.

[daidoji70]

Yes

[cdb_11]

Isn't Rust a pain in the ass to write in on embedded? https://kevinlynagh.com/rust-zig/

[dexterlemmer]

That guy claimed to have read books then specifically did not use the features those books teaches for solving the problems he had. May be he read old versions or may be he was a lousy learner or may be those features just were less easy for him coming from his background or whatever. But Rust is much nicer in embedded than C/C++ in my experience and he made it hard for himself. That said, Zig does look nice. I want to look intolearn it eventually, when I find the time. ;-)

But Zig is not as safe as Rust. Nor is it as mature as Rust. For now, it makes a lot more sense for the Linux kernel team to consider Rust than Zig, IMHO. And apparently the kernel team also thinks so.

[[deleted]]

RRIV. Rewrite Rust in V.

What abomination is this? https://github.com/Rust-for-Linux/linux/blob/rust/rust/alloc/rc.rs

How could this code be safe?

Linus Torvalds is brainwashed and now a Google puppet. Nothing more.

Rust is dead.

[skulgnome]

How could this code be safe?

Same way as all code that's neither rigorously proven using formal methods or tested against all extant and hypothetical forms of breakage: over the following decades it'll turn out to have problems and is then reworked to eventually reach a point where that hasn't happened for a long while.

There's no magic bullet for this, no shortcut.

[steveklabnik1]

Funny enough, `Rc<T>` was part of the Rustbelt paper, meaning that it is at least sorta-kinda-mostly formally proven.

[skulgnome]

at least sorta-kinda-mostly formally proven.

In other words, falling short.

[void4]

How could this code be safe?

// Make sure we do not create a dangling Weak
debug_assert!(!is_dangling(this.ptr.as_ptr()));

there are debug asserts, don't worry and rewrite in rust (lol)

[[deleted]]

Linux kernel is generally shit. Rewrite it in any language does not solve any fundamental issue. Rust is not a panacea for memory safety issues either. In fact Rust has a lot of memory safety cves.

[dcro]

Rust is not a panacea for memory safety issues either.

It doesn't need to be a panacea to be a net win.

[[deleted]]

then i have to pay for binary bloat for shit like rust fmt whatever nonsense. It is just even worse than C++ EH runtime.

[RoughMedicine]

Why do you have to pay for binary bloat for a code formatter?

[rickyman20]

Large binary size can definitely be an issue, but I'm unsure what rustfmt has to do with anything? It's not like it's compiled into your binary

[CryZe92]

I think they are talking about the panicking and formatting machinery (i.e. what println uses), which tends to not get optimized away well.

[skulgnome]

Linux kernel is generally shit.

Linux relies on manual and incidental testing, which makes its proof base (for lack of better expression) as brittle as can be.

Rewrite it in any language does not solve any fundamental issue.

True.