Rust was not exempt from the criticisms of Linus Torvalds

Few weeks ago the news of about some implementations that were made in the linux-next branch, which includes an initial set of components to develop device drivers in the Rust language.

This documentation was published separately on the use of Rust in the Linux kernel and an example of a kernel module with a character device driver in the Rust language. The code was added by Stephen Rothwell, maintainer of the branch.

After that Linus Torvalds went over the implementation review patch of possibilities to set Rust language drivers in Linux kernel and voiced some criticism.

The biggest complaints were caused by escape potential "Run-time failure panicen" in wrong situations, for example, in an out-of-memory situation, when dynamic memory allocation operations, including kernel operations, may fail.

Torvalds stated that such a focus on the kernel is fundamentally unacceptable, And if you don't understand this point, you can completely reject any code that tries to use such an approach. On the other hand, the developer of the patch agreed with the problem and found it solvable.

Another problem has been attempts to use floating point or 128 bit types, which are not valid for environments like the Linux kernel.

You may not understand the ramifications of when it can happen, so maybe
is less of a problem than I think it is, but fundamentally
I think if any Rust mapping can cause panic this is simply
_ fundamentally_ not acceptable.

Mapping failures in a non-core controller or code, and that is, for
definition, all new Rust code, can never NEVER cause
panic validly. The same goes for «oh, in some cases I did not try the use of
128-bit integers or floating point '.

So if the Rust compiler causes hidden assignments that cannot be
detect and return as errors, then I seriously believe that all of this
approach should be completely NAK'ed, and the Rust infrastructure,
either at compiler level or in kernel wrappers, you need more
job.

This turned out to be a more serious problem., since at this moment Rust's central library is indivisible and represents a large stain; there is no way to request only some of the features, thus avoiding the use of one or another problematic functionality.

The solution to the problem may require changes to the rust compiler and library, although the team does not yet have a strategy on how to implement modularity for language libraries.

In addition, Torvalds pointed out that the provided example controller is useless and advised to attach as an example a driver that solves one of the real problems.

Before this Google announced its participation in an initiative to promote Rust support in the Linux kernel y provided technical aspects of the feasibility of implementing Rust to combat problems that arise from errors in working with memory.

Google thinks Rust is ready to join C as a development language Linux kernel components. The article also provides examples of the use of the Rust language to develop kernel drivers, in the context of its use on the Android platform (Rust is recognized as an officially supported language for Android development).

Note that Google has prepared an initial prototype of a controller written in Rust for Binder's inter-process communication mechanism, which will allow a detailed performance and security comparison of Binder implementations in C and Rust.

In its current form, the work is not yet complete, but for almost all the basic abstractions of kernel functionality required for Binder to work, layers have been prepared to use these abstractions in the Rust code.

Finally, if you want to know more about it, you can check the details In the following link.