Microsoft Engineer Advances Rust integration in Linux kernel with Module initialization patches

The patches were sent on March 26, 2024

Reading time icon 3 min. read


Readers help support Windows Report. We may get a commission if you buy through our links. Tooltip Icon

Read our disclosure page to find out how can you help Windows Report sustain the editorial team Read more

Microsoft Engineer Advances Rust integration in Linux kernel with Module initialization patches

Microsoft has been contributing to the Linux kernel for quite some time now, and the introduction of Rust programming language support is one of the examples.

This time, Wedson Almeida Filho, a Microsoft engineer who works closely in the Rust for Linux initiative, has revealed that patches have been sent to revolutionize module initialization within the kernel.

The latest patches, by Filho, show Microsoft’s commitment to facilitating the growth of Rust within the Linux ecosystem. These patches will refine the Allocation APIs for Rust Kernel code and introduce a new concept, i.e., in-place module initialization for Rust kernel modules

The second iteration of the Rust Allocation APIs for the Linux kernel:

We currently have a fork of the crate with changes to `Vec`; other changes have been upstreamed (to the Rust project). This series removes the fork and exposes all the functionality as extension traits.

Additionally, it also introduces allocation flag parameters to all functions that may result in allocations (e.g., `Box::new`, `Arc::new`, `Vec::push`, etc.) without the `try_` prefix — the names are available because we build `alloc` with `no_global_oom_handling`.

Lastly, the series also removes our reliance on the `allocator_api` unstable feature.

Long term, we still want to make such functionality available in upstream Rust, but this allows us to make progress now and reduces our maintainance burden.

In summary:

  1. Removes `alloc` fork
  2. Removes use of `allocator_api` unstable feature
  3. Introduces flags (e.g., GFP_KERNEL, GFP_ATOMIC) when allocating

Changes in v2: –

  • Updated description of `alloc` crate.
  • Renamed vecext and boxext modules to vec_ext and box_ext.
  • Added derive directive to `AllocError`.
  • Updated safety comment in `BoxExt::new`.
  • Updated `VecExt::push` and `VecExt::extend_from_slice` to use `spare_capacity_mut`
  • Add directive to not compile `destructure` and `rebuild` in when `test` or `testlib` are configured. Otherwise we have a warning because `push` and `extend_from_slice` don’t use them anymore.
  • Updated indentation in `Arc::new_uninit`
  • Moved the removal of `TryReserveError` convesion to `Error` to patch 7, where usage of `TryReserveError` is actually removed.

Earlier, the module initialization in the Linux kernel included returning an instance that would be moved to its designated memory space.

However, with the new patches, modules can be initialized directly in their intended memory location. This eliminates the need for unnecessary memory allocations and lets modules proficiently manage complex data structures such as locks.

Filho further said:

This allows us to have modules whose state hold objects that must be initialized in place like locks. It also allows us to implement registrations (e.g., driver registration) in place and have them similar to their C counterparts where no new allocations are needed.

This development has profound implications. By using Rust’s capabilities for in-place initialization, kernel developers can efficiently initiate modules and optimize memory usage.

In addition, this step will line up Rust-powered modules more closely with their C counterparts, which will reduce the gap between conventional and modern kernel development practices.

What was once thought of as an unusual union now seems to be the attestation of the transformative power of collaboration and innovation

What are your thoughts on the matter? Share your opinions with our readers in the comments section below.

More about the topics: Linux, microsoft