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

[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.

[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.

[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.

[dc740]

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

[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.

[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.

[jacob]

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.

Rust is like C++ in that regard. It has its own ABI, but can use the C one when needed.

[jacob]

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.

It's not all about dyn traits, the return types, iterators etc will always need per-instance monomorphisation. Of course if your code only ever uses integers then it's not a problem, it will monomorphise once and as you say, it's the same code you SHOULD write in C anyway. You can also do it the "C" way by boxing everything, again it will monomorphise just once for pointers. That would be even more efficient than dyn traits, because box pointers are raw pointers while dyn traits use fat pointers.

Of course you also need to consider the case for using Rust in the first place on such a ultra low end, ultra cheap microcontroller. If you are writing code for a TV remote, the safety guarantee requirements are exactly zilch, so there is no actual problem with using plain C if it means less workarounds.

[darkonix]

Of course you also need to consider the case for using Rust in the first place on such a ultra low end, ultra cheap microcontroller. If you are writing code for a TV remote, the safety guarantee requirements are exactly zilch, so there is no actual problem with using plain C if it means less workarounds.

The remote could be an attack vector for your smart TV, which is basically a computer with a big screen, and may have network access and even a microphone and camera. A cheap TV remote sounds an interesting target. But let's not tell that to the various governments sponsoring high level hacking organizations just yet ;-)

[jacob]

The remote could be an attack vector for your smart TV, which is basically a computer with a big screen, and may have network access and even a microphone and camera. A cheap TV remote sounds an interesting target. But let's not tell that to the various governments sponsoring high level hacking organizations just yet ;-)

A remote can send messages to the TV over infrared but never actually receives any input. All it does is react to keypresses, one at a time. So even if the code it runs is theoretically vulnerable as hell, in the context there is basically no way to exploit it.