The currently usable features of the new Linux 6.3 make the kernel release look like a maintenance release. Inside, however, major upheavals are looming.
Apart from some architecture-specific parts in assembler, the Linux kernel is written in the C programming language. New functions and drivers could only be incorporated as C code. What was long considered established is increasingly softening. In addition to the rapid steps to integrate Rust into the kernel, eBPF is also increasingly becoming an alternative to bring functionality previously reserved for C into the kernel.
Extended Berkeley Packet Filter: Red-Black-Trees für eBPF
Linux 6.3 allows access to the kernel’s “red-black trees” (rbtrees) from eBPF programs. The rbtrees are a form of binary search trees that the kernel uses extensively in many places, including file systems, I/O and CPU schedulers, and network protocols. eBPF programs can access the trees and add and delete nodes via a (still) rudimentary API (Application Programming Interface). This API is expected to be expanded in future kernel versions.
This direct access to the rbtrees out of eBPF is remarkable. 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, kernel functions for eBPF were already directly accessible. At that time, this step could still be explained with the goal of “unification”. The restrictions on accessing kernel functions prior to 5.13 simply created a parallel world in eBPF so that important kernel functions could still be used. “TCP Congestion Control” was a pioneer and special case at the time.
By opening the rbtrees for eBPF it behaves differently now. Normally, such new APIs are only included if there is already a specific use case in the kernel itself. However, this time there is no such thing. Rather, it is a question of setting the course for the future. In this context, the statements made by eBPF maintainer Alexei Starovoitov at the “Linux Plumbers Conference 2022” in Dublin make people sit up and take notice. The intention behind the work on eBPF is to create a more secure version of the C programming language for kernel programming.
eBPF is thus positioning itself to introduce new and secure alternative functions into the kernel in the future. Since eBPF also bridges the gap between user space and kernel space with its helper functions, this is undoubtedly reminiscent of a microkernel architecture through the back door.
Linux 6.3: Rust integration advances
Rust has officially arrived in the kernel since Linux 6.1, but even with the Rust extensions in Linux 6.2, there is hardly anything comprehensible about small examples and demos like a “Hello, world!” out. But behind the scenes, the banging and hammering on the Rust framework is progressing surprisingly quickly and practically.
A practical use case is a graphics driver for Apple hardware that Asahi Lina programs in Rust and already in the September 2022 in development stage brought to work. For the driver, the developer needs a number of Rust modules that do not yet exist in the kernel infrastructure. For Kernel 6.3, she is contributing some of the puzzle pieces for the big Rust picture. One of the Japanese’s modules shows the challenges of integrating Rust in the kernel.
Lina contributed, among other things module for time functions. There are several timing functions in the kernel ktime_*all the time essentially as 64-bitInteger or C-union more diverse Integers in seconds or nanoseconds, depending on the variant. Like this one Integer-value to be interpreted depends on the function that supplied it. there ktime_get_boottime() the seconds since system start again, ktime_get_real() However, the seconds back since January 1st, 1970, i.e. in Epoch/Unix time. It is therefore always a difference to a fixed point in time that varies. However, this fixed point is nowhere visible in the returned value.
