The next major version bump for the Linux kernel won’t be 7.0 — it will be 8.0. In a move that underscores Linus Torvalds’s pragmatic and sometimes whimsical approach to version numbering, the creator of Linux has confirmed that the kernel will skip version 7.x entirely when the time comes to move beyond the current 6.x series. The reasoning is characteristically Torvalds: old user-space code that parsed kernel version strings couldn’t properly handle single-digit minor numbers following a single-digit major, and jumping to 8.0 sidesteps the problem entirely.
This revelation is just one of several notable developments emerging from the Linux kernel community as it barrels toward what will eventually become a historic version transition. Phoronix recently published an extensive review of the features and changes that have already been queued or discussed for the post-6.x era, offering a detailed look at what kernel developers and enterprise users can expect in the years ahead.
The Version Number That Will Never Exist
Torvalds has long treated kernel version numbers as essentially arbitrary milestones rather than indicators of dramatic feature changes. The shift from 5.x to 6.0 in October 2022 happened simply because the minor version numbers were getting unwieldy — 5.19 was the last in that series. Torvalds has indicated that a similar threshold will trigger the next bump, likely when the 6.x series reaches somewhere around 6.19 or 6.20.
But when that bump happens, it won’t land on 7.0. As reported by Phoronix, the problem traces back to legacy user-space applications — some still in production — that parsed the kernel version string using a format that multiplied the major version by 65,536, the minor version by 256, and added the patch level. Under this scheme, version 7.0 would produce a numerical value lower than some 6.x releases, potentially confusing or breaking old software. Skipping straight to 8.0 avoids this entirely, since 8.0.0 under the old formula would produce a value safely above any 6.x or hypothetical 7.x release.
Rust in the Kernel: From Experiment to Infrastructure
Perhaps the most consequential technical shift underway in the Linux kernel is the expanding role of the Rust programming language. What began as an experimental infrastructure merged in Linux 6.1 has grown steadily, and by the time the kernel reaches its next major version, Rust is expected to be deeply embedded in driver development and possibly in core subsystems.
The Rust-for-Linux effort has already produced working GPU drivers — most notably for Apple’s M-series chips via the Asahi Linux project — and there are active efforts to write network drivers, file system components, and other modules in Rust. The appeal is straightforward: Rust’s memory safety guarantees can eliminate entire classes of bugs that have historically plagued C-based kernel code, including buffer overflows and use-after-free vulnerabilities. According to Phoronix, the kernel community expects Rust adoption to accelerate significantly through the remaining 6.x releases, setting the stage for a much more mature Rust infrastructure by the time 8.0 arrives.
Arm Architecture and RISC-V Gaining Ground
The x86 architecture has dominated Linux kernel development for decades, but the balance is shifting. Arm-based processors are now powering everything from smartphones and Chromebooks to data center servers from Ampere Computing and Amazon’s Graviton line. Each kernel release brings expanded support for new Arm SoCs (system-on-chip designs), improved power management, and better performance tuning for server-class Arm hardware.
RISC-V, the open-source instruction set architecture, is also commanding increasing attention from kernel developers. While RISC-V hardware is still relatively niche compared to x86 and Arm, the architecture’s open nature has attracted significant investment from companies like SiFive, StarFive, and various Chinese semiconductor firms. Linux kernel support for RISC-V has been improving rapidly, with new extensions, better boot support, and performance optimizations landing in nearly every release cycle. By the time the kernel version number rolls past 6.x, RISC-V support is expected to be substantially more mature, potentially making it a viable platform for certain server and embedded workloads.
File Systems and Storage: Bcachefs and Beyond
The Linux kernel’s file system stack continues to evolve. Bcachefs, the copy-on-write file system developed by Kent Overstreet, was merged into the mainline kernel in Linux 6.7 after years of out-of-tree development. The file system aims to combine the reliability and feature set of ZFS and Btrfs with better performance and a cleaner codebase. However, its inclusion has not been without controversy — Overstreet’s sometimes combative interactions with other kernel developers have generated friction, and the file system is still considered experimental for production use.
Meanwhile, ext4 and XFS continue to receive incremental improvements. Btrfs, once seen as the future default file system for many distributions, has stabilized considerably and is now the default on openSUSE and Fedora Workstation. The ongoing work in all of these file systems reflects a broader trend: storage performance and reliability remain among the most active areas of kernel development, driven by the demands of NVMe SSDs, persistent memory, and increasingly large-scale storage deployments.
Scheduling, Performance, and the sched_ext Framework
One of the more exciting developments in recent kernel releases is sched_ext, a framework that allows BPF (Berkeley Packet Filter) programs to implement custom CPU scheduling policies. Merged in Linux 6.12, sched_ext enables developers and system administrators to write, test, and deploy scheduling algorithms without modifying the kernel itself. This has significant implications for workloads ranging from gaming (where latency-sensitive scheduling can improve frame rates) to cloud computing (where custom schedulers can optimize for specific workload patterns).
As noted by Phoronix, the sched_ext framework is expected to see substantial refinement and adoption through the remaining 6.x releases. Several distributions, including CachyOS and Fedora, have already begun experimenting with sched_ext-based schedulers. By the time the kernel reaches 8.0, custom scheduling via BPF could be a standard tool in the performance tuning toolkit for both desktop and server workloads.
Graphics, Display, and the Expanding Role of Open-Source GPU Drivers
The Linux graphics stack has undergone a transformation in recent years, and the pace of change shows no signs of slowing. AMD’s open-source AMDGPU driver continues to be the gold standard for Linux GPU support, with new hardware generations typically receiving day-one or near-day-one support. Intel’s Xe driver for Arc and integrated graphics has also matured, though it has faced more growing pains.
NVIDIA remains the outlier. While the company has released open-source kernel modules for its newer GPUs, the user-space driver components remain proprietary. The Nouveau project, which provides a fully open-source NVIDIA driver, has historically been hamstrung by NVIDIA’s lack of documentation and firmware support. However, recent developments — including NVIDIA’s release of GPU System Processor (GSP) firmware and improved cooperation with the open-source community — suggest that the situation may improve over the next several kernel cycles. The Nova driver project, which aims to build a new NVIDIA kernel driver in Rust, represents another potential avenue for progress, though it remains in early stages.
Security Hardening and the Shadow Stack
Kernel security continues to be a major focus. Intel’s Shadow Stack support, which provides hardware-enforced protection against return-oriented programming (ROP) attacks, has been integrated into the kernel and is expected to see broader adoption as more distributions enable it by default. Arm’s equivalent technology, Guarded Control Stack (GCS), is also progressing through the kernel development pipeline.
Lockdown mode, Landlock (a stackable security module for unprivileged sandboxing), and ongoing work to reduce the kernel’s attack surface through configuration options and code auditing all contribute to a steadily hardening security posture. These efforts are particularly important as Linux continues to expand its presence in security-sensitive environments, from cloud infrastructure to automotive and industrial systems.
What the Road to 8.0 Actually Looks Like
It bears repeating that Linux kernel version numbers do not correspond to dramatic feature releases in the way that, say, Windows version numbers historically have. The transition from 6.x to 8.0 will happen when Torvalds decides the minor version number has gotten large enough to be annoying — likely sometime in 2026 or 2027 at the current pace of roughly six to seven releases per year.
In the meantime, every two-month release cycle brings hundreds of thousands of lines of changed code, contributed by thousands of developers employed by companies including Intel, AMD, Google, Red Hat, Meta, Microsoft, and many others. The features outlined above — Rust integration, new scheduling frameworks, expanded architecture support, file system development, graphics driver improvements, and security hardening — will arrive incrementally, as they always have. The version number on the tin will change, but the relentless, methodical pace of Linux kernel development will not.