Recently Miguel Ojeda, author of the Rust-for-Linux project released the fifth proposal Linux kernel developers of choice for development components Rust device drivers for them to consider.
For those who are still unaware of this series of proposals that have been published for several months now, you should know that the idea behind it is due to the fact that Rust support is currently considered experimental, but is already included in the linux-next branch and is mature enough to start working on creating abstraction layers about the kernel subsystems, as well as writing drivers and modules.
Currently, Miguel Ojeda's development commission is financed by Google and the ISRG (Internet Security Research Group), which is the founder of the Let's Encrypt project and promotes HTTPS and the development of technologies to increase Internet security.
It is important to mention that the proposed changes they make it possible to use Rust as a second language for developing drivers and kernel modules. Rust support is presented as an option that is not enabled by default and does not result in Rust being included among the required build dependencies for the kernel.
Using Rust to develop drivers will allow you to create better and safer drivers with minimal effort, without problems like accessing a memory area after freeing it, dereference null pointers, and buffer overflows.
Memory safety is provided in Rust at compile time by checking references, tracking object ownership, and object lifetime (scope), as well as by evaluating the correctness of memory access during the execution of the code. Rust also provides integer overflow protection, requires variables to be initialized before use, better handles errors in the standard library, enforces the concept of immutable variables and references by default, and offers strong static typing to minimize logical errors. .
Main novelties in the fifth proposal
In the new version of the patches, continued deleting comments made during the discussion of the first, second, third and fourth edition patches.
In the part of the changes and improvements that have been made we can find that the component validation for compatibility with Rust has been added to the continuous integration system based on the Intel compatible 0DAY/LKP bot and test reports have started to be published.
In addition to this, it is highlighted that integration of Rust support is being prepared in automated test system KernelCI, plus GitHub CI based tests were switched to using containers.
It is also highlighted that added the ability to define additional parameters when registering devices, as well as the is_rust_module.sh script has been redesigned and that support for static synchronization primitives (global shared variables) based on the "CONFIG_CONSTRUCTORS" implementation was added.
Of the other changes that stand out in this new controllers proposal:
- Rust Core modules are spared the need to define the attributes: "#![no_std]" and "#![feature(...)]".
- Added support for single build targets (.o, .s, .ll, and .i).
- The code guidelines now define rules for delimiting comments ("//") and documenting code ("///").
- Simplified lock management: Guard and GuardMut are combined into one parameterized type.
- Added the "RwSemaphore" abstraction, which acts as a wrapper over the C rw_semaphore structure.
- To use mmap, a new mm module and a VMA abstraction (binding on the vm_area_struct structure) have been added.
- The PL061 GPIO controller was changed to use the "dev_*!" macro.
- General code cleanup.
Finally if you are interested in knowing more about it about this new proposal, you can consult the details In the following link.