Kernel Articles in LWN

posted by Roy Schestowitz on Nov 30, 2023

• Faster kernel testing with virtme-ng

  Building new kernels and booting into them is an unavoidable—and time-consuming—part of kernel development. Andrea Righi works for Canonical on the Ubuntu kernel team, so he does a lot of that and wanted to find a way to speed up the task. To that end, he has been working on virtme-ng, which is a way to boot a new kernel in a virtual machine, and it does so quickly. He came to the 2023 Linux Plumbers Conference (LPC) in Richmond, Virginia to introduce the project to a wider audience.

  His team builds lots of kernels for multiple architectures, often applying patches and fixes that need to be tested to ensure that they work and do not introduce regressions. There is a large testing infrastructure for that, but sometimes developers want to get more "hands on" with these kernels, for example to do a git bisect. There are often lots of build-reboot cycles for the work that he does, so his goal to reduce the time that they take.

• The push to save Itanium

  It is (relatively) easy to add code to the kernel; it tends to be much harder to remove that code later. The most recent example of this dynamic can be seen in the story of the ia64 ("Itanium") architecture, support for which was removed during the 6.7 merge window. That removal has left a small group of dedicated ia64 users unhappy and clinging to a faint hope that this support could return in a year's time.

  At the end of the 1990s, it had become clear that 32-bit processors were approaching the end of their useful life for many applications; in particular, 32 bits is not enough to address the memory sizes that were beginning to show up on higher-end systems. In response, Intel launched into a program that it called "Merced" to create the successor to the x86. It was a RISC architecture, wholly incompatible with anything that Intel had sold before. But it was going to be the Next Big Thing because that was what Intel was doing.

  At the time, information about this new architecture was being held under nondisclosure agreements, and it was far from clear when Linux developers would be able to port the kernel to Merced, if ever. This was before Intel's investment in Red Hat that signaled the beginning of the arrival of big money into Linux. It seemed entirely possible that Linux would be cut out of the processor that, we were all reliably informed, would be the future of computing; choices would be limited to Windows and proprietary Unix.

• listmount() and statmount()

  Years ago, the list of mounted filesystems on a Unix or Linux machine was relatively short and static. Adding a filesystem, which typically involved buying a new drive, happened rarely. In contrast, contemporary systems with a large number of containers can have a long and dynamic list of mounted filesystems. As was discussed at the 2023 LSFMM+BPF Summit, the Linux kernel's mechanism for providing information about mounted filesystems has not kept up with this change, leading to system-management headaches. Now, two new system calls proposed by Miklos Szeredi look set to provide some much-needed pain relief.

  Even in the absence of containers, the list of mounted filesystems on a typical Linux system has grown, partly as a result of an increase in the number of virtual filesystems provided by the kernel. For example, on your editor's basic desktop system, /proc/self/mountinfo lists 34 mounts, few of which correspond to partitions on actual storage devices. As this virtual file gets longer, it becomes harder for system-management tools (and humans too) to work with. The new system calls, called listmount() and statmount(), provide an alternative to digging through the mountinfo file.

• The rest of the 6.7 merge window

  By the time that the 6.7 merge window closed on November 12, 15,418 non-merge changesets had been pulled into the mainline kernel. That makes this one of the busiest merge windows ever; if one discounts the lengthy bcachefs development history (some 2,800 commits), though, then the patch volume is roughly in line with other recent kernels. Over 5,000 of those commits were merged after our first-half merge-window summary was written.