40 million lines of code: how the Linux kernel is changing in 2026

Everything makes perfect sense. The Linux kernel has long become part of a vast global infrastructure — with tens of millions of lines of code, thousands of developers from companies around the world, and constant pressure from demands for performance, security, and energy efficiency. Therefore, the community is forced not only to maintain the current level of stability but also to experiment, striving to make the system more flexible and reliable. In 2026, several directions of such work have emerged — from Rust and schedulers to support for new architectures. Let's take a look at what's happening here.

Rust in the kernel: from experiment to everyday use

One of the most noticeable events in recent years is that Rust has de facto stopped being perceived as something unusual. At the end of 2025, the community officially removed the experimental status, and development accelerated: tens of thousands of lines are already present in drivers, subsystems, and new components. Developers appreciate the built-in protection against memory errors — the very ones that have plagued life in classic C for decades.

The evolution is going relatively smoothly, although there are some minor issues. Some of the old maintainers still view Rust with skepticism, especially when it comes to complex subsystems like GPU drivers. It is important to understand that no one is planning to rewrite the entire kernel from scratch — millions of lines of C continue to live their own life. Nevertheless, for new drivers and individual components, the advantages of Rust are obvious: it is easier to attract developers accustomed to modern tools and to reduce the risk of typical errors even at the coding stage. This year, the infrastructure around Rust continues to be improved: the integration with existing C code is being enhanced, build tools are being refined, and the groundwork for larger components is being prepared.

This approach reduces the risk of errors and does not disrupt the current process. Companies receive a more stable base for development, while the community gains new contributors.

Schedulers and a focus on efficiency

Another important topic is the task scheduler. It currently handles typical scenarios well, but systems with different types of cores and accelerators require more flexibility. This issue is being addressed through sched_ext — a way to try new scheduling approaches without changing the core itself.

This year, there is also discussion about adding GPU awareness to sched_ext and mechanisms for smart task distribution considering power consumption. The system will be able to offload tasks to more energy-efficient components. This is important for both servers in data centers and mobile devices, where every watt counts. Not all participants in the process are convinced that the eBPF approach is ideal for such critical tasks, but the developments are already showing real improvements.

Meanwhile, the main scheduler is also being refined. How exactly? Its behavior is being made smoother in interactive scenarios and more stable in virtual environments. As a result, the system behaves more predictably — both on servers and on regular workstations.

The topic of power consumption is also not going away. With the increasing complexity of processors, the kernel must more frequently work precisely with frequencies, container loads, and actual resource consumption.

New architectures and ecosystem growth

RISC-V continues to gain popularity. The open architecture attracts manufacturers of embedded systems, IoT gadgets, and even servers. Support in the kernel is developing rapidly: vectorization is improving, extensions are added to accelerate computations, including machine learning tasks. By this year, RISC-V is already becoming a real alternative in several segments, especially in embedded devices and specialized equipment.

Large companies are actively developing RISC-V and supporting it in Linux. For example, Google and Intel are participating in international initiatives to develop the RISC-V ecosystem and optimize its software components. Meanwhile, Qualcomm regularly submits patches to improve RISC-V support in the kernel. This helps expand the market and accelerate the adoption of the architecture in various devices and systems.

The ecosystem around the kernel is also expanding. Documentation is gradually being simplified, mentorship programs and tools are emerging, which lower the entry threshold for new developers. The Linux Foundation and individual vendors support such initiatives, including outside traditional development hubs.

In addition to RISC-V, the community is actively working with other promising architectures as well. LoongArch — a Chinese project — by the beginning of 2026 is receiving more mature support: in the upcoming releases, a 32-bit version (LA32R and LA32S) has appeared. Plus, there are already real devices on the market — mini-PCs and laptops powered by Loongson processors, where Linux runs stably and shows good performance compared to traditional platforms.

Backup scenario for managing the Linux kernel

A document that has garnered significant attention at the beginning of the year deserves special mention. Media headlines like "The world is preparing for Linux without Torvalds" appeared, but it's not so bleak. A new section informally called a conclave has been added to the kernel documentation, describing a backup scenario in case key project integrators — primarily Linus Torvalds and his closest assistants — are unable to fulfill their duties for any reason. This is unlikely (at least for now), but not impossible.

The idea took shape after discussions at the Maintainers Summit in December 2025. The session on Linux stability and reducing external risks was led by Dan Williams from Intel. He initiated a conversation about the risks to the project in unforeseen situations. Ultimately, participants agreed that such a plan is necessary, but without a rigid hierarchy or a predetermined successor.

What was decided? In an emergency situation, the organizer of the last summit (or a representative of the Technical Advisory Board) quickly gathers a meeting of key maintainers. Online or offline — whichever is more convenient, the main thing is to have as many people attend as possible. At this meeting, dubbed a conclave (hinting at the election of a pope and white smoke), they decide how to manage the main branch going forward. The goal is simple: to choose the option that best preserves the health of the project and the community in the long term.

The decision can be anything: one person, a group, or even a committee. Within a couple of weeks, the results are published openly, and the Linux Foundation assists with the technical side. The document emphasizes that this is indeed a backup scenario. If Torvalds decides to leave voluntarily, he will organize everything himself, like any other maintainer.

By the way, it is informally discussed that Greg Kroah-Hartman could take on this role in a transitional situation. The thing is, he has already temporarily replaced Torvalds several times and is responsible for the stable branches of the kernel. At the same time, the document itself intentionally avoids specific names: what matters are not positions, but real experience and contributions to the project. But for now, Torvalds himself has no plans to go anywhere.

As a result, the year 2026 for the Linux kernel began without sharp changes, but with noticeable shifts within the project. The volume of kernel code has already exceeded 40 million lines, and the number of active contributors continues to grow. Rust is gradually finding its place, schedulers are becoming more flexible, support for architectures is expanding, and formal processes are reducing risks around management. Development continues.