Kernel Coverage in LWN, Especially Latest Event/Talks
-
The 2022 Linux Kernel Maintainers Summit [LWN.net]
After a two-year hiatus, the 2022 Linux Kernel Maintainers Summit returned to an in-person format in Dublin, Ireland on September 15. Around 30 kernel developers discussed a number of process-related issues relating to the kernel community. LWN had the privilege of being there and is able, once again, to report from the event.
-
Better regression handling for the kernel [LWN.net]
The first scheduled session at the 2022 Linux Kernel Maintainers Summit was a half hour dedicated to regression tracking led by Thorsten Leemhuis. The actual discussion took rather longer than that and covered a number of aspects of the problem of delivering a kernel to users that does not break their applications. Leemhuis started by saying that, after a break of a few years, he has managed to obtain funding to work as the kernel's regression tracker and is back at the job. He has created a new bot intended to minimize the amount of work required and to, he hopes, enable effective regression tracking while not creating additional overhead for developers. In an ideal world, bug reporters will put bot-related directives into their reports, after which the bot will track replies. When it sees a patch with a Link tag pointing back to the report, it will mark the bug as resolved.
This application (called "regzbot") is still young, he said, and it has its share of warts and deficiencies. It has reached a point of being useful for Linus Torvalds, but it is not yet as useful for subsystem maintainers. It is, in any case, far better than trying to track bugs manually. Regzbot has already caught regressions that would have otherwise fallen through the cracks. He thanked Meta for providing the funding that makes this work possible.
-
Next steps for Rust in the kernel [LWN.net]
The Rust for Linux project, which is working to make it possible to write kernel code in the Rust programming language, has been underway for a few years, and there is a growing number of developers who feel that it is time to merge this work into the mainline. At the 2022 Linux Kernel Maintainers Summit, Miguel Ojeda updated the group on the status of the project with the goal of reaching a conclusion on when this merge might happen. The answer that came back was clear enough: Rust in the kernel will be happening soon indeed.
There was little suspense on that front; Linus Torvalds spoke up at the beginning of the session to say that he plans to accept the Rust patches for the 6.1 kernel (likely to be released in mid-December) unless he hears strong objections. Ojeda indicated that he would like to see that happen and asked how the patches should be routed into the mainline. Torvalds said that he would rather not accept them directly, so it seems likely that Kees Cook will be routing this work upstream.
-
How far do we want to go with BPF?
The BPF subsystem has come a long way in recent years; what started as a mechanism for implementing packet filters has become a way to load code into the kernel for a wide variety of tasks. At the 2022 Linux Kernel Maintainers Summit, Jiri Kosina kicked off a session by asking how far the transition to BPF should go. The actual scope of the session turned out to be rather more limited than that, and no fundamental changes were considered.
Kosina started by saying that BPF has been highly successful and it is increasingly being used by user programs. But the kernel community has no policies about out-of-tree BPF code and, in particular, how to deal with associated bug reports. What happens when a kernel change breaks somebody's BPF program? Ted Ts'o added that future applications are increasingly likely to include BPF scripts, and users may not be aware that they are running something that is more like a kernel module than an ordinary program. That can lead to confusion and complaints to kernel developers when things break.
-
Various short development-process topics
The final part of the 2022 Linux Kernel Maintainers Summit included a number of relatively short discussions on a variety of topics. These included testing of stable updates, compiler versions, test suites, and the traditional session where Linus Torvalds talks about his happiness (or lack thereof) with the way the development process is going.
-
Introducing io_uring_spawn [LWN.net]
The traditional mechanism for launching a program in a new process on Unix systems—forking and execing—has been with us for decades, but it is not really the most efficient of operations. Various alternatives have been tried along the way but have not supplanted the traditional approach. A new mechanism created by Josh Triplett adds process creation to the io_uring asynchronous I/O API and shows great promise; he came to the 2022 Linux Plumbers Conference (LPC) to introduce io_uring_spawn.
Triplett works in a variety of areas these days, much of it using the Rust language, though he has also been working on the kernel some of late. He is currently working on build systems as well. Build systems are notorious for spawning lots of processes as part of their job, "so I care about launching processes quickly". As with others at this year's LPC, Triplett said that he was happy to see a return to in-person conferences.
-
The road to Zettalinux [LWN.net]
Nobody should need more memory than a 64-bit pointer can address — or so developers tend to think. The range covered by a pointer of that size seems to be nearly infinite. During the Kernel Summit track at the 2022 Linux Plumbers Conference, Matthew Wilcox took the stage to make the point that 64 bits may turn out to be too few — and sooner than we think. It is not too early to start planning for 128-bit Linux systems, which he termed "ZettaLinux", and we don't want to find ourselves wishing we'd started sooner.
The old-timers in the audience, he said, are likely to have painful memories of the 32-bit to 64-bit transition, which happened in the mid-1990s. The driving factor at the time was file sizes, which were growing beyond the 2GB that could be represented with signed, 32-bit numbers. The Large File Summit in 1995 worked out the mechanisms ("lots of dreadful things") for handling larger files. Developers had to add the new lloff_t size for 64-bit file sizes and the llseek() system call to move around in large files. Wilcox said that he would really prefer not to see an lllseek() for 128-bit offsets.