Kernel watch

2 min read

Jon Masters keeps up with all the latest happenings in the Linux kernel, so you don’t have to.

Linus Torvalds announced both the release of Linux 6.4, and the first release candidate for what will become Linux 6.5 in another couple of months. Linux 6.4 had few “big ticket” user visible features (although it did include initial Apple Silicon M2 chipset support) but instead made many internal changes, such as the removal of the SLOB memory allocator, support for Intel’s LAM (Linear Address Masking) for pointer tagging feature, and the capability to support educating userspace about which of the growing zoo of extensions a given RISC-V implementation might actually be implementing via riscv_hwprobe.

Linux 6.5 is shaping up to be another release with more below the surface, mostly focused on scalable performance. For example, it includes a patch series that parallelizes the boot process on x86 CPUs, potentially leading to a 10x speedup (don’t get excited, this only applies to very large systems). But the topic that will probably get the most attention isn’t so much what made it into 6.5 as what did not…

Don’t have a cow, man!

Discussed more in depth in the column this month is a thread on the Linux Kernel Mailing List in which the developer’s attempt to get a new feature into the kernel and the resulting debate caused a kerfuffle. Bcachefs is a copy-on-write (COW) filesystem with features similar to ZFS or Btrfs in which updates to files aren’t made in-place, but instead result in copies of the modified regions being stored, and housekeeping updated afterward. Such filesystems are popular for performance and robustness reasons, with the author of Bcachefs claiming it is “The COW filesystem for Linux that won’t eat your data”. Whether or not it delivers on these promises, Bcachefs has been under active development out-of-tree (not upsteam) for over 7 years – you can find more about its design philosophy, including downloads, at bcachefs.org.

The reason Bcachefs didn’t make 6.5 wasn’t entirely technical. There were a few small bugs under discussion, but the major concern from many high-profile maintainers can perhaps best be summarized in this rely to the author: “you do not always assume that your conversational partner is trying to raise objections in good faith. You also want to assume that you are the smartest person in