Linux 6.11: More Rust, Torvalds adds "Runtime Constants"

Contents

The latest incarnation of the Linux kernel saw the light of day in the night from Sunday to Monday. While the "extensible scheduler" was eagerly awaited for Linux 6.11, the new scheduler has been left out at this time. Instead, Linux father Torvalds himself is introducing a mechanism for "runtime constants". The expansion of Rust is also progressing.

No extensible scheduler

Contrary to Linus Torvalds' plans to include the extensible scheduler(sched_ext) in Linux 6.11, it is now not part of the new kernel. Torvalds actually no longer wanted to postpone the flexible scheduler based on eBPF. In the future, the developers should join forces to resolve any problems that arise in the mainline kernel. Torvalds once again made it clear that he is no friend of new features developed outside the kernel (out of tree). So far, this has been the case with the extensible scheduler.

Since Torvalds' announcement to include the eBPF-based scheduler, there have been some problems with its code. It no longer "got along" so smoothly with the rest of the kernels. Torvalds did not consider the additional more than 14,000 lines of code around the scheduler submitted by Tejun Heo for Linux 6.11 via pull request. Torvalds did not comment on his rejection.

However, a comment by Qais Yousef addresses the reasons presumably responsible for the rejection. The behavior of the scheduling and the kernel would probably change significantly if sched_ext were loaded. How can bug reports and regression reports still be trusted if the behavior of the kernel is massively changed, argues Yousef. The inclusion would be rushed and would go in the wrong direction. This leaves sched_ext out of the picture for now. It is currently unknown when and in which Linux release the new additional scheduler will be included in the mainline kernel.

Block devices in Rust

The new kernel supports the programming of drivers for block-oriented devices (block devices) in Rust for the first time. This means that drivers can be written for hard disks or DVD drives, for example. Although this has so far only been used by the zero-block driver, it should make it easier to develop block device drivers in the mainline kernel in Rust.

The zero-block driver emulates block-oriented devices and makes them available as /dev/nullb0, /dev/nullb1 et cetera. It is used in benchmarks for block layer implementations and is therefore not intended for productive systems, but is used for development and testing. It is also a basic driver with manageable C source code.

These properties make it the ideal candidate for safely taking your first steps with block devices in Rust. The Rust driver rnull is available for selection in the kernel configuration(make menuconfig) in the block devices as BLK_DEV_RUST_NULL. Once selected, it acts as an experimental replacement for the "normal" null block device. However, so far, it is only an "economy version" of the original driver.

Firmware via Rust

In addition, an abstraction layer for the Linux firmware API is now available. This is a first step towards loading firmware from Rust code. The API allows firmware updates to be loaded from user space. In this way, errors in the microcode of the processors can be eliminated or firmware for microcontrollers on devices such as data carriers, expansion cards and controllers can be updated.

This abstraction layer is necessary to be able to program "real" drivers for devices in Rust in the future. Finally, practical Rust drivers will also be able to adapt the firmware of the associated devices. Another piece of the puzzle for the overall picture of "device drivers in Rust" has thus been laid. However, a few more pieces are still missing before any drivers can be programmed in Rust in the same way as in C. The gaps in the picture are slowly but surely shrinking.