Linux Coverage From Jakub Kicinski, LWN, Mike Blumenkrantz, and Arun Raghavan
-
Kernel Space
-
Linux ☛ netdev in 2024 — Jakub Kicinski
Developments in Linux kernel networking accomplished by many excellent developers and as remembered by Andew L, Eric D, Jakub K [...]
-
LWN ☛ Kicinski: netdev in 2024
Kernel networking maintainer Jakub Kicinski reviews progress in
the networking subsystem in 2024.
-
LWN ☛ A 2024 retrospective
We started with a prediction that the kernel community would (slowly) begin to move away from email during this year. With a suitably broad interpretation of "slowly", this prediction was not entirely wrong. A search for "b4 relay" return addresses in the kernel's mailing-list archives shows that some people are, indeed, submitting patches without using an email client. There are also, as related in the 2024 Maintainers Summit, some beginning experiments with the use of Forgejo for kernel development, but nothing is yet available to the public. It is a slow beginning indeed; email remains central to the development process.
The next long-term-stable kernel release was 6.12, just as predicted, but we were two weeks off on the release date. In modern times, every kernel development cycle is nine or ten weeks long; our estimate included more ten-week cycles than actually happened. In fact, the only ten-week cycle was 6.7, released just after the new year. The longer cycles, it would seem, are becoming increasingly uncommon. The development cycle is becoming more predictable — and we failed to predict it.
The first user-visible Rust code (an Asix PHY driver) was indeed merged in 6.8 as predicted. While that merging was not the explicit declaration of success for the Rust experiment that had been predicted, it has become increasingly clear over the course of the year that Rust is in the kernel to stay. Whether the lack of a GCC-based Rust compiler actually became a bigger problem as predicted is debatable at best, though; much of the community would appear to be at ease with the existence of a single compiler for the language.
-
LWN ☛ Process creation in io_uring
Back in 2022, Josh Triplett presented a plan to implement a "spawn new process" functionality in the io_uring subsystem. There was a fair amount of interest at the time, but developers got distracted, and the work did not progress. Now, Gabriel Krisman Bertazi has returned with a patch series updating and improving Triplett's work. While interest in this functionality remains, it may still take some time before it is ready for merging into the mainline.
A new process in Linux is created with one of the variants of the clone() system call. As its name suggests, clone() creates a copy of the calling process, running the same code. Much of the time, though, the newly created process quickly calls execve() or execveat() to run a different program, perhaps after performing a bit of cleanup. There has long been interest in a system call that would combine these operations efficiently, but nothing like that has ever found its way into the Linux kernel. There is a posix_spawn() function, but that is implemented in the C library using clone() and execve().
-
-
Graphics Stack
-
Mike Blumenkrantz: Manifested
I’m not saying we’re doing it
Don’t quote me. We’re not doing it.
Unless we are, in which case everything I wrote last year may come to pass with the advent of the unified OpenGL/ES ‘25 release. This is not a release announcement, but I’m tentatively planning to provide the date of the announcement once the ray-tracing EXT goes live.
-
-
Multimedia
-
Arun Raghavan ☛ Arun Raghavan: A Brimful of ASHA
It’s 2025(!), and I thought I’d kick off the year with a post about some work that we’ve been doing behind the scenes for a while. Grab a cup of
$beverage_of_choice, and let’s jump in with some context.[...]
I am delighted to announce that we were able to find the financial support to complete the PipeWire work! Once we land basic mono audio support in the MR above, we’ll move on to implementing stereo support in the BlueZ plugin and the PipeWire module. We’ll also be testing with some real-world devices, and we’ll be leaning on our community for more feedback.
-