A Default Architecture: How RISC-V Quietly Became a First-Class Citizen in the Kernel
If you built or ran computers for a living in the 1990s, you remember when the processor was a decision rather than an assumption. A Sun workstation running SPARC sat in one corner of the engineering room. A DEC Alpha promised a speed nobody was quite sure what to do with. Silicon Graphics put MIPS under the machines that rendered the era's films, and IBM shipped POWER into the back office. x86 was the cheap option, not the obvious one. I have compiled more kernels than I can count, starting on a 486, and for a good stretch of those years part of the job was accepting that the instruction set underneath the whole edifice was somebody else's decision, made in a boardroom I would never sit in. Then x86 won the desktop, ARM took the phones, and the question of who owns the instruction set stopped being asked out loud.
It is being asked again. The answer arrived, as these answers usually do, in a commit that almost nobody noticed.
On 12 July 2026 Linus Torvalds released Linux 7.2-rc3, the third release candidate for the next kernel. One outlet described the release as normal-looking, which it was [1]. Among the changes was a single, undramatic addition: support for UltraRISC hardware was enabled in the RISC-V default kernel configuration, the defconfig, bringing an eight-core desktop-grade RISC-V processor called the UR-DP1000 into a standard kernel build with no manual configuration required [1][2]. There was no press release and almost no coverage outside the people who read kernel mailing lists for a living. That quiet is the whole point.
Supported is not the same as default
RISC-V has been a supported Linux architecture since kernel 4.15 in January 2018, when the initial port, driven by SiFive and the University of California, Berkeley team, landed in the mainline [3]. Supported means you can build a working kernel for the architecture. Default means something quieter and more consequential: the kernel community considers the hardware mature enough for mainstream use without special handling, the configuration you compile against when you ask for nothing in particular. The gap between supported and default is eight years wide, and it is where driver work, hardware maturation and community trust accumulate, usually with no announcement at either end.
RISC-V itself is not a chip. It is an open, royalty-free instruction set architecture, the contract that defines how software talks to a processor. It was designed at Berkeley from 2010 by Krste Asanovic, David Patterson and their graduate students, governed since 2015 by a non-profit standards body, RISC-V International, and merged into Linux in 2018 [3]. The point that makes it different from x86 or ARM is simple: any nation, company or institution can implement it without a licence from a single owner. There is no ARM Holdings to pay and no Intel to ask.
The land under the house
Two things make this the natural next episode rather than a detour. The first is that A Concise History of Linux has spent its whole run tracing one question down through the layers of the stack. It started with software freedom, the right to read and change the code, protected by the GPL. It moved last month to language, the shift to Rust for memory safety, which is really a question about who controls the guarantees your code rests on. The instruction set is the layer underneath all of it. My own view, and I will put it plainly as a view rather than a finding, is that software freedom without hardware freedom is renting the land under the house. You can own the building outright and still not own the ground it stands on.
The honest objection deserves an airing, because a careful reader will raise it. An open specification is not the GPL. The GPL guarantees you the right to read and modify a specific body of code. An open instruction set guarantees only that the contract is unowned; it does nothing to stop a company from designing a closed, proprietary implementation of that contract and selling it to you as a black box. The freedom is at the floor, not the ceiling. What it buys is narrower than the GPL and still worth having: no single company can revoke your right to build on the architecture, price you out of it, or be leaned on by a government to cut you off from it. In a decade that has made supply-chain control an instrument of policy, an unowned floor is not nothing.
What "first-class citizen" actually means
One commit does not make an architecture mainstream. A run of them, arriving from different directions at once, does. RISC-V International reports that it has grown to more than four thousand six hundred members across over seventy countries, with more than two billion RISC-V-based chips in production and a projection of twenty billion by 2031 [8]. I would attribute that figure carefully, because it comes from the organisation's own annual report and RISC-V International is an interested party in its own growth story; treat it as directional, not audited. Alongside it, Canonical shipped Ubuntu 26.04 LTS in April 2026 as the first major long-term-support release to target the RVA23 profile by default, the curated set of instruction-set extensions that lets general-purpose software assume a stable RISC-V baseline without conditional compilation [6][7]. And in March 2026 Alibaba's DAMO Academy released the Xuantie C950, a sixty-four-bit RISC-V processor built on a five-nanometre process at up to 3.2 gigahertz [11]. The performance claims around the C950 are the manufacturer's own and I will not repeat them as verified benchmarks; the existence of a production-grade, high-frequency RISC-V desktop part from a company of that size is the point that matters.
The hardware in the kernel commit fits the same pattern. UltraRISC Technology is a processor developer headquartered in Shanghai, with research centres in Changsha and Wuxi. Its UR-DP1000 carries eight of the company's UR-CP100 cores, runs at up to two gigahertz, and offers PCI Express 4.0 and dual DDR4 memory channels; it ships on the Milk-V Titan family of mini-ITX boards [4][5]. Membership, chip volume, a long-term-support distribution and a place in the default kernel build: put those four together and you have what "first-class citizen" means in 2026. Not a headline. A baseline.
The same question, three ways
The reason this is not merely a hardware story is that three of the world's largest actors are pursuing open silicon at the same time, each for a different reason. China has mandated RISC-V adoption across critical infrastructure sectors including finance, energy and telecommunications, and Alibaba's Xuantie line is the systematic domestic investment that mandate implies; China is now the dominant producer of RISC-V chips by volume. I will state that as the reportable fact it is, and note that a widely circulated figure putting China at close to half of global RISC-V shipments traces back to a press-release distribution network rather than an audited source, so it does not belong in this article as a number [8]. The European Union is chasing the same architecture for a different motive: its Digital Autonomy with RISC-V in Europe initiative, and the OpenHW Foundation's TRISTAN project hosted by the Eclipse Foundation, frame open silicon explicitly as the foundation of a European sovereign technology stack, one not dependent on an instruction set owned by a UK-incorporated, SoftBank-owned company [9][10]. India is further back, with the Indian Institute of Technology Madras working towards a seven-nanometre RISC-V processor reported to be targeting 2027, a stated intention rather than a shipped fact [9].
Here is the part worth sitting with. The kernel commit that started this article says nothing about any of that. It does not mention China. It does not mention sovereignty. A developer added hardware support to a default configuration because the hardware met the community's bar for mainstream, and that is all the commit records. The absence of any geopolitical commentary is not an oversight; it is how the kernel community has always treated hardware. The instruction set became a contested national asset while the people merging the patches were simply deciding whether the drivers were good enough.
There is a New Zealand thread in this for me, and it is not nostalgia. For thirty years I have watched organisations here treat the layer beneath the application as somebody else's problem, right up until the vendor changed the terms, retired the platform, or was bought by a company with different priorities, and the architecture that had been a background fact became a line item and a scramble. The lesson RISC-V is quietly teaching is the one this series has argued from the start: the layer you do not control is the layer that eventually controls you, and the time to care about it is before it moves, not after.
The commit in 7.2-rc3 will not trend. It closes no chapter with a flourish. What it marks is the moment the kernel community stopped treating open silicon as an experiment and started treating it as expected, the same unglamorous institutional shift that once turned Linux itself from a hobby into infrastructure. The ownership question the series has followed from a Usenet post in 1991 has reached the instruction set, and it got there without anyone raising their voice.
There is a defence and sovereignty layer here that needs no forcing. The United States National Aeronautics and Space Administration chose a RISC-V design, built on SiFive cores, for its next-generation High-Performance Spaceflight Computing processor, the flight computer meant to run trusted systems whose hardware cannot be quietly swapped out or remotely revoked [13]. The United States Defense Advanced Research Projects Agency built its System Security Integration Through Hardware and Firmware programme on RISC-V for the same reason: an open instruction set can be inspected, audited and built without a licence from a company a rival state could pressure [14]. When the layer beneath a trusted system is a contract no single entity owns, the sovereignty argument this series has followed reaches the silicon: the specification that lets a Shanghai company build a desktop chip lets an allied programme build one it can fully account for.
When did a processor architecture last make a decision for you? An end-of-life you did not choose, a port that would not port, a platform that vanished under a system you relied on. I would like to hear what it taught you about who really owns the stack.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." He can be reached at linux@linux.co.nz. A Concise History of Linux chronicles the operating system that changed the world and the lessons it holds for the AI era.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
References
[1] Larabel, M. "Linux 7.2 Enabling UltraRISC RISC-V Support In The Default Kernel Build." Phoronix. July 2026. https://www.phoronix.com/
[2] Neowin. "Normal-looking Linux 7.2-rc3 lands with fixes for SEGA Dreamcast driver." neowin.net. July 2026. https://www.neowin.net/
[3] RISC-V International. "RISC-V Getting Started Guide" and Linux kernel release history (RISC-V merged in Linux 4.15, January 2018). riscv.org / kernel.org. 2018. https://riscv.org/
[4] UltraRISC Technology. "UR-DP1000 Product Overview." ultrarisc.com. 2026. https://www.ultrarisc.com/
[5] Ganesh, T. "Milk-V Titan Mini-IX board with UR-DP1000 processor shows RISC-V ecosystem taking shape." Tom's Hardware. 2026. https://www.tomshardware.com/
[6] Canonical. "Canonical and Ubuntu RISC-V: a 2025 retro and looking forward to 2026." ubuntu.com. 2026. https://ubuntu.com/
[7] Halfacree, G. "Canonical Declares That 2026 Is the Year of Ubuntu Linux on the RISC-V Desktop, Server, and More." Hackster.io. 2026. https://www.hackster.io/
[8] RISC-V International. "2025 Annual Report" (membership, chip volume, and projection figures; interested-party source, attributed). riscv.org. 2026. https://riscv.org/
[9] Eclipse Foundation. "The OpenHW Foundation unveils the first industry-ready RISC-V ecosystem to advance European digital sovereignty." Eclipse Newsroom. 2026. https://www.eclipse.org/
[10] The Stack. "Europe bets on RISC-V for 'sovereign' tech stack." thestack.technology. 2026. https://www.thestack.technology/
[11] Alibaba DAMO Academy. "Xuantie C950 RISC-V processor" (release 26 March 2026; specifications; performance claims are manufacturer claims). 2026. https://www.t-head.cn/
[12] RISC-V International. "Three high-performance RISC-V processors to watch in H2 2025." riscv.org blog. 2025. https://riscv.org/blog/
[13] NASA. "High-Performance Spaceflight Computing (HPSC) Processor" (RISC-V design on SiFive cores, developed with Microchip Technology). nasa.gov. 2022. https://www.nasa.gov/
[14] Defense Advanced Research Projects Agency. "System Security Integration Through Hardware and Firmware (SSITH)." darpa.mil. https://www.darpa.mil/