Rust For The Linux Kernel Sent Out For Review A Fourth Time

[MartinN]

Yes, a significantly less portable bastardized mix.

To my (limited) knowledge, Rust has the same ABI as C. In this sense, any Rust code introduced into the kernel, should be portable going forward. Rust is an awesome addition to Linux, one that will transform the entire kernel into a more stable, less buggy, more easily testable/performant piece of code.

[mmstick]

Even then, pretty much everything in libcore (not even speaking about std) tends to return Option or Result and so there is still quite a lot of monomorphisation going on. Of course this will be increasingly irrelevant as even the cheapest microcontrollers' memory increases but as of today it's one of the use cases where C can be preferable. There is also the problem that Rust doesn't yet support nearly as many target architectures as C, especially microcontrollers.

Nothing prevents people from writing the same kind of code they were already writing in C though. You don't have to rely on monomorphism at that level. But even if you do, it's still generating code that you would have otherwise have written by hand anyway. And there are ways to give hints to the compiler to encourage it to not inline anything. There's also some useful crates that can automatically convert impl return types into enums, which are 10x faster than trait objects while not needing allocations.

But I wouldn't be so quick to judge the memory consumption of monomorphism. There were prior attempts by Rust's compiler team to investigate automatically converting generic type definitions into dyn traits and trait objects, and it actually generated more code, used more memory, and burned more CPU cycles. This is something that you need to be very careful with measuring.

[dc740]

Great news! I hope to see it merged some day.

[jacob]

That depends on what you use. If it's actually a problem, you can just use boxed trait objects. Then you know the size, and it's not going to be large, but you will trade some performance for it.

Even then, pretty much everything in libcore (not even speaking about std) tends to return Option or Result and so there is still quite a lot of monomorphisation going on. Of course this will be increasingly irrelevant as even the cheapest microcontrollers' memory increases but as of today it's one of the use cases where C can be preferable. There is also the problem that Rust doesn't yet support nearly as many target architectures as C, especially microcontrollers.

[krzyzowiec]

Using gets() should be a criminal offense but other than that C is in many cases (unfortunately) still the go-to language for microcontrollers. The reason is binary size. In Rust virtually everything uses generic types (even in libcore) which need monomorphising. The resulting binary is often significantly larger than if it was written in C. For many applications it's the price worth paying for Rust's advantages (and honestly whether an executable is 20kb or 500kb absolutely doesn't matter on a PC), but with a 16-bit address space it's a problem.

That depends on what you use. If it's actually a problem, you can just use boxed trait objects. Then you know the size, and it's not going to be large, but you will trade some performance for it.

I wonder if explicitly typing some generic functions you actually do use with many types (and not something that compacts greatly from monomorphization, like iterator chains) to take `&mut dyn Trait` would produce code sizes closer to C. A common example could be when you pass many structs implementing `Serialize` to the same data format.

Yes, that's the main reason to use trait objects.

[krzyzowiec]

There are no features that must be abstained from when doing low-level things, there is no "unsafe" portion of the language that one must rely exclusively on in these low-level scenarios.

Lol, that's because the whole language is unsafe.

[qm3ster]

In Rust virtually everything uses generic types (even in libcore) which need monomorphising.

I wonder if explicitly typing some generic functions you actually do use with many types (and not something that compacts greatly from monomorphization, like iterator chains) to take `&mut dyn Trait` would produce code sizes closer to C. A common example could be when you pass many structs implementing `Serialize` to the same data format.

[billyswong]

The last x86 CPU that didn't support SSE2 came out in ~2002. So you won't be able to run the latest software on 20 year old x86 CPUs. I think we'll survive.

Well, there are always some strange products like this https://www.phoronix.com/scan.php?pa...inux-Detection
From that presentation slide, they are still introducing new x86 CPU in 2018. However, according to the news writing their whole series aren't even fully i686 ready.

[AmericanLocomotive]

I'm not a fan of rust, whether iron oxide based or language.

Look at rust's history of support.

Litterly took a crap on older CPU's lacking SSE2 CPU optimization while supporters kept the bugs or lack of support extremely quiet, all awhile furthering it's own agenda in-filtering top coding projects in order to enrich it's own fame. Reminds me of Ubuntu and SystemF.

On the flip, rust will likely have a very successful time of further deleting all of the older (and slower) CPU code from the kernel, making the kernel smaller and faster!

The last x86 CPU that didn't support SSE2 came out in ~2002. So you won't be able to run the latest software on 20 year old x86 CPUs. I think we'll survive.

[pabloski]

Rust support can be merged if it supports at least half of those architectures: Alpha, ARC, ARM, C6x, C-Sky, H8/300, Hexagon, IA-64, m68k, Microblaze, MIPS, NDS32, Nios II, OpenRISC, PA-RISC, PowerPC, RISC-V, s390, SuperH, SPARC, Unicore32, x86, Xtensa

Rome wasn't built in one day. x86_64 and ARM are the most used ISAs today. This means that Rust is ready to replace C for a lot of drivers.

And at least both GCC and LLVM.

Why GCC? The kernel can be compiled with Clang too. And Clang today is on par with GCC. There are very few corner cases where Clang produces binary code that is incompatible with GCC. So you can even compile Rust parts with Clang and the rest with GCC.