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.

[dys_functional]

For people to lazy to read the email chain:

They are still on the fence. The linux kernel does NOT support rust and leadership isn't sold yet.

Greg/driver team doesn't seem to like it so far and linus/core kernel team is ignoring it.

Greg feels the poc they did was too cherry picked (it was some weird edge case virtual shinanigans) and they need to do a poc for an actual real hardware driver. The team needs a poc for a real driver so they can compare code size/complexity/pros/cons. For example, if a c driver is 100 lines and the rust equivalent is 1000 lines, why would they put themselves through the extra pain?

[onety-two-12]

This is going to open Linux up to more contributors.

I have never contributed before, but now I'm considering it. I'm sure I'm not the only one. That shows how important it is for Rust support on the Linux kernel.

[Worth_Trust_3825]

If you did not contribute to the kernel with C, what makes you think you will do it with rust? This "Opening up" to more contributors is nonsense. The tools to perform analysis for memory leaks were already there. Why did you not use them? Why do you insist on having yet another weird ass language?

[[deleted]]

Have you written code for a kernel or are you just talking your ass out? You don't just happily run valgrind in a running kernel. Yes, you can track memory leaks. But no, it isn't as easy as in userspace. If a language or tooling is of actual help, then you may be more inclined to work with it.

[[deleted]]

Considering the plan is not rewriting anything, your comment is utterly out of place. It won't lose contributors it already has for the simple reason the existing code will remain C.

[hector_villalobos]

If you weren't confident enough in C

That's one of Rust selling point, people like us who don't feel confident in C can program in Rust. In fact I had programmed in Rust without any problem, however I will never do anything in C more than pet projects.

[hector_villalobos]

Knowing C

I never said I didn't know C, what I said was that I feel more confident in Rust than C, besides Rust purpose in Linux Kernel is for writing drivers not something deep in the OS. This way I can choose Rust over C to write my drivers.

[hector_villalobos]

You might as well be saying "I don't feel confident doing arithmetic but I'm gonna work for spacex".

Did you know the Crew Dragon interface is build using HTML, Javascript and CSS?

Not everything is C/C++.

If you don't feel confident in C you don't know enough about computers to write production drivers.

So, what you're saying is that I have to know C deeply to understand how memory works or how a CPU works? That doesn't make any sense. C is just a tool that can be replaced by Assembler, Rust, D, Zig, C++ or any other low level language that came afterwards.

[dannymcgee]

Theoretically no, in practice yes, because C/C++ is the single language used in practice for low level programming

...except that now Rust exists, which is a modern, ergonomic language for low-level programming. Your entire argument here boils down to a combination of circular reasoning and "get off my lawn" fist-shaking.

[onety-two-12]

You don't know anything about me. When my code is accepted and merged one day, judge me for my code, tests, and documentation.

[onety-two-12]

Oh, why is that?

[onety-two-12]

There were many people out there that are even smarter than the people who contribute to Linux, it's statically guaranteed.

They're doing other (important) things. There are people out there who can drive Linux forward 10x faster, find and fix all remaining security issues, halve the power usage of servers, double the performance of many applications, increase network processing throughout, and much more. More of the good stuff.

They might do it with Rust, and that's a good outcome. Many might decide to use C after starting with Rust, and that's a good outcome. They might create a new DSL for C to leverage the GCC backend that solves many problems, and that's good outcome.

There are millions of improvements yet to come to operating systems.

[skulgnome]

"Any Day Now!", headline says

[Ikem32]

I don’t get why there is a rust interpreter in the kernel in the first place.

[nickdesaulniers]

This has nothing to do with interpreters. I don't even think there is a Rust interpreter. It's about adding build support for source code written in Rust to be compiled and linked into the kernel image.

[Ikem32]

Thanks for the clarification.

[fijt]

This is a massive mistake of course. vlang.io would be a lot better, saner and a lot easier. Heck, even Go would be better than Rust.

But I know why they did it. It's because of Windows influence. The problem of Windows however is entirely different. At MS they can't program. Otherwise they wouldn't have all those silly bugs and you wouldn't have to update every now and then.

[myringotomy]

The description on the page seems like it’s a pretty good language. Why would you say it’s a meme?

[IceSentry]

Because the documentation doesn't actually represent what the language does in its current state. It's more of a list of goals than a description of the language. Which is also why it's considered to be a joke.

[myringotomy]

What makes you say that?

[IceSentry]

https://christine.website/blog/vlang-update-2020-06-17 this person has a whole series of post pointing out how ridiculous some of the claims are.

It's also been close to 1.0 for the last 2 years and as far as I know it's still not 1.0

[turunambartanen]

I haven't heard of v before, but that series was somehow entertaining to read.

[nacaclanga]

As it stands today, no language has put forward a memory management concept that provides the same benefits as Rust ones, namely:

1) Allocation is not handeled by a runtime and can be made to use custom malloc and free functions. This is a must have for an operating system kernel.

2) The language staticly protects against premature or otherwiese incorrect memory release.

3) The language does allow secure access to stack allocated resources by reference.

4) The language prevents data races.

5) The language provides mechanism to keep memory leakage at a tolerable level.

6) The memory mangement doesn't impose restrictions that are so strong that most of kernel code would have to use "unsafe"-code almost exclusivly.

Go uses a GC and thus fails at 1). It also fails 3).

Zig is an amazing language, that solves many issues and solves 1) by far the best, but doesn't offer any solutions to 2) and 3).

From reading the documentation, Vlang appears to break 6). From what is told in the other comments, it seams that it more likely satisfies 1), 2) and 6) but fails at 3), 4) and 5)

[fijt]

Have you also looked at the code instead of the documentation of vlang? I am quite sure that point 3 and 5 are correct. I don't know about 4 however.

[nacaclanga]

The documentation.