Linus Torvalds: Rust For The Kernel Could Possibly Be Merged For Linux 5.20

[sinepgib]

Heeee ? Every high level language gets compiled to turn into assambler the machine language, thats what compilers are for, because nobody nowdays knows how to realy code assembler anymore, and even if it would take a horrible amount of time to write a simple programm in assembler, so i guess thats just not true. Thats why you also need multiple tools compiler truns it to assembler then the linker runs that code again and forms the actual binary wich then is just a jumbo mumbo of hex data, basically unreadable by a human being.

Since you generally* don't read the assembly output, the compiler can turn your C code into the jumbo mumbo of hex data without going through the intermediate text representation. Which is also a bit of a lie because compilers use their own low level representation in many cases.

*Unless you specifically want to, in which case you pass a flag to the compiler so it outputs it.

Besides, there are sections of code where you can't avoid assembly. Some parts of the interrupt handling and setting of memory mappings are often done in assembly (tho I think GCC does provide extensions for most of it), and some performance sensitive code is written with explicit usage of SIMD extensions in plain assembly.

[Almindor]

I like Rust but it sucks that it doesn't yet have async functions in traits. 😭️
It also sucks that async is shattered islands with non-interoperable packages that depend on a specific async runtimes. 😭️

Same. I really like Rust but async is FUBAR to the point is being better ignoring it. Problem in the userland level is that loads of basic crates you NEED will force async on you, in most cases pushing for a specific runtime too. Good luck with the x-lib interop on that.

[NobodyXu]

Same. I really like Rust but async is FUBAR to the point is being better ignoring it. Problem in the userland level is that loads of basic crates you NEED will force async on you, in most cases pushing for a specific runtime too. Good luck with the x-lib interop on that.

Doesn matter for the Linux kernel, since it has its own async executor/locking mechanism/io types, so it only has one async environment for rust to support.

[Developer12]

It is highly probable that the Native GCC frontend is done enough in the beginning of 2023. I don't see why the extreme rush to merge rust support still in 2022.

They want it merged because continuing to port it to new kernels sucks.

It has language bindings that rely on every single kernel subsystem not changing, or they break. Each time there's a change anywhere the bindings need to be adapted to match it. This is a pain that is intentionally inflicted on all out-of-tree code but rust pays for it across every part of the tree it touches, which is way more code than usual compared to some random driver.

The sooner they're in-kernel, the sooner they don't face a hailstorm of breaking changes from every other kernel developer combined.

[oleid]

Some people asked on twitter about this https://twitter.com/fasterthanlime/s...34725185191937, can you explain more about why Tokio is far from ideal for single threaded async ?

Check out this discussion:
https://www.reddit.com/r/rust/commen...e_the/ibqc0bw/

Short summary:

• When configuring Tokio to use a single threaded executor your futures still need to be Send and 'static (although we are in a single threaded context where this shouldn't have to be required).
• You can, however, use a workaround via LocalSet, however that's a 2nd class citizen and more verbose than for other executors

[mdedetrich]

The lack of language support for HKTs is also frustrating. You can kinda hack them in and somehow works, but it's far from ideal. I was hoping the likes of Amazon and Microsoft getting involved would speed things up, but sadly it seems a bit like Rust development has somewhat stagnated.

As someone that programs in languages that have HKT's (Scala, bit of Haskell in the past) you are unlikely to find an ergonomic implementation of HKT's in Rust because it would require a lot of boxing behind the scene's which is against one of the main design goals of Rust/C++ (zero cost abstraction).

Afaik its also the same reason where there is so many issues with async + traits in Rust currently.

I am also very keen on Rust, but I think these shortcomings that a lot of pure functional programmers notice you will just have to accept because the whole point of Rust is that its a low level language that gives you precise control of memory allocation and also doesn't do silent techniques behind the scenes (such as boxing) just for ergonomic reasons.

If you are expecting these things in Rust than Rust is not the language for you (not saying Rust shouldn't try to adopt HKT's, but just adjust your expectations around it).

[archkde]

Check out this discussion:
https://www.reddit.com/r/rust/commen...e_the/ibqc0bw/

Short summary:

• When configuring Tokio to use a single threaded executor your futures still need to be Send and 'static (although we are in a single threaded context where this shouldn't have to be required).
• You can, however, use a workaround via LocalSet, however that's a 2nd class citizen and more verbose than for other executors

I'm really puzzled here, I'm working on code right now where the futures are neither Send nor 'static, but for some reason, it works anyway (even with the default multithreaded executor, where it clearly shouldn't work…).

[Sin2x]

Linus has become too soft with age. Linux needs somebody like Theo de Raadt.

[moltonel]

It is highly probable that the Native GCC frontend is done enough in the beginning of 2023.

Gcc as an additional backend of the existing rustc compiler (rustc_backend_gcc) is already usable (just hard to install, and a few gotchas like missing unwinding and incomplete simd) whereas the new from-scratch frontend of gcc (gcc-rs) is still missing some fundamental language features. It's unclear how far behind rustc will gcc-rs be in a year's time (as opposed to rustc_backend_gcc which should always remain current), but given how rustforlinux uses bleeding-edge rustc features and tooling, it's safe to say that compiling the kernel with gcc-rs is many years in the future. Also, looking at the effective adoption failure of gcc's other also-ran frontends for Go and D (both much simpler languages than Rust) should dampen your expectations about gcc-rs.

TL;DR: You should get excited about rustc_backend_gcc, not gcc-rs.

I don't see why the extreme rush to merge rust support still in 2022.

Merging rust support is not being rushed, it seems to be going at a normal pace for this kind of feature. The current patchset is relatively limited and has been reviewed and discussed for a long time already. Many people eagerly await the feature.

There's no reason to wait for either gcc-rs or rustc_backend_gcc before merging rust support. LLVM-built Linux is fine for the vast majority of systems that people care about, it's notably used for pretty much all Android kernels. Rust is explicitly kept out of Linux's core features for now, so gcc-only arches won't regress. Remember that Linux already has lots of features that don't work on all arches, there's nothing special about rust in that regard.

[piotrj3]

Since you generally* don't read the assembly output, the compiler can turn your C code into the jumbo mumbo of hex data without going through the intermediate text representation. Which is also a bit of a lie because compilers use their own low level representation in many cases.

*Unless you specifically want to, in which case you pass a flag to the compiler so it outputs it.

Besides, there are sections of code where you can't avoid assembly. Some parts of the interrupt handling and setting of memory mappings are often done in assembly (tho I think GCC does provide extensions for most of it), and some performance sensitive code is written with explicit usage of SIMD extensions in plain assembly.

You sort of are correct, but here we are arguing about semantics. Assembly and hexcode binary with executable code are 1-1 translatable to assembly unless we involve special tricks like packers or self modyfing code which doesn't really happen in most programs except malware and anti-RE programs.


If you talk about stuff like LLVM IR, those are higher level then assembly. Anyway most compilers allows outputting assembly that will be 1-1 to binary.