Linux 6.3: Paving the way to move away from C

The features currently used in the new Linux 6.3 make the kernel release look like a maintenance release. Inside, however, major unrest is looming.

Apart from some architecture-specific parts in the assembler, the Linux kernel is written in the C programming language. New functions and engines can only be integrated as C code. What was long considered well-established is increasingly fading away. In addition to the rapid integration of Rust into the kernel, eBPF is also increasingly becoming an alternative to bringing functions previously reserved for C into the kernel.

Berkeley extended packet filter: eBPF red-black trees

Linux 6.3 allows access to the “red and black trees” in the kernel (rbtrees) from eBPF software. the rbtrees They are a form of binary search tree that is widely used by the kernel in many places, including file systems, I/O scheduling, CPU and network protocols. eBPF programs can access trees and add and delete nodes via a (still) primitive API (API). This API is expected to be extended in future kernel releases.

This direct access to rbtrees The eBPF is awesome. Until now, complex data structures from the kernel could only be used as eBPF maps. The eBPF engine in the kernel had neither the privileges nor the need to manipulate complex data structures in the kernel.

With Linux 5.13, the kernel functions for eBPF were already directly accessible. At that time, this move could still be explained by the aim of “unification”. Restrictions on accessing kernel functions prior to 5.13 created a parallel universe in eBPF so that important kernel functions could still be used. TCP congestion control was a pioneering and special case at the time.

By opening a file rbtrees For eBPF, it behaves differently now. Typically, these new APIs are only included if a specific use case already exists in the kernel itself. However, this time there is no such thing. It is about setting the course for the future. In this context, the remarks made by Alexei Starovoitov, eBPF maintainer at the “Linux Plumpers 2022 Conference” in Dublin, make people sit up and take notice. The goal of working on eBPF is to create a safer version of the C programming language for kernel programming.

The eBPF is thus positioning itself to introduce new and safe alternative functions into the kernel in the future. Since eBPF also bridges the gap between user space and kernel space with its auxiliary functions, this is undoubtedly reminiscent of the kernel’s microarchitecture through the backdoor.

Linux 6.3: Rust integration progress

Rust has officially arrived in the kernel since Linux 6.1, but even with the Rust extensions in Linux 6.2, there’s hardly anything comprehensible about small examples and demos like “Hello, world!” Outside. But behind the scenes, beating and knocking on the Rust tire progresses surprisingly quickly and functionally.

A practical use case is a graphics driver for Apple devices that Asahi Lina drivers in Rust and in September 2022 In development brought to work. For the driver, the developer needs a number of Rust modules that are not yet in the kernel infrastructure. For Kernel 6.3 it contributes some puzzle pieces to the big Rust image. A Japanese module shows the challenges of integrating Rust into the kernel.

Lena contributed, among others unit of time functions. There are many timing functions in the kernel ktime_*all the time mainly as 64-bitInteger monster-union more versatile Integers in seconds or nanoseconds, depending on the variable. like this Integer– The value to be interpreted depends on the function you provide. there ktime_get_boottime() seconds since the system started again, ktime_get_real() However, it returns the seconds since January 1st, 1970, i.e. in Epoch/Unix time. Therefore, the difference is always at a specific point in time varies. However, this fixed point is not visible anywhere in the returned value.