You’re right. But consider that in order to be useful when not fused off, the design would need to have a bunch of additional logic (interconnect ports, power control machinery etc) at the periphery of the to-eventually-be-fused-off area that would likely remain even when things were fused off. That may impact power.
Apart from that there’s the other usual angles: The very fact that there’s additional logic in the compute path (eventually fused off) means additional design and verification complexity. The additional area, although dark, eats into the silicon yield at the fab.
A large motivation for this move is likely to ensure that attempts by some incumbent ISAs to lobby the US government to curb the uptake of RISC-V are stymied.
There appears to be an undercurrent of this sort underway where the soaring popularity of RISC-V in markets such as China is politically ripe for some incumbent ISAs to turn US government opinion against RISC-V, from a general uptake PoV or from the PoV of introducing laborious procedural delays in the uptake.
Turning the ISA into an ISO standard helps curb such attempts.
Ethernet, although not directly relevant, is a similar example. You can't lobby the US government to outright ban or generally slow the adoption of Ethernet because it's so much of a universal phenomenon by virtue of it being a standard.
Then, there's NASA, and their rad hard HPSC RISC-V. It's a product now, with a Microchip part number (PIC64-HPSC1000-RH) and a second source (SiFive, apparently.) I suppose it's conceivable the a Berkeley CA developed ISA that has been officially adopted as new rad hard avionics CPU platform by the US government's primary aerospace arm could get voted off the island in some timeline, but it's looking fairly improbable at this point.
Only time will tell if it ends like: "to avoid someone else shooting us, let's shoot ourselves".
Dedicated consortiums like CNCF, USB Implementers Forum, Alliance for Open Media, IETF, etc are more qualified at moving a standard forward, than ISO or government bodies.
> There appears to be an undercurrent of this sort underway where the soaring popularity of RISC-V in markets such as China is politically ripe for some incumbent ISAs to turn US government opinion against RISC-V, from a general uptake PoV or from the PoV of introducing laborious procedural delays in the uptake.
> Turning the ISA into an ISO standard helps curb such attempts.
Why do you think that would help? I fail to see how that would help.
An ISO standard is hard to gepolitically regulate, I would think.
It also cements the fact that the technology being standardized is simply too fundamental and likely ubiquitous for folks to worry about it being turned into a strategic weapon.
Taking the previously mentioned ethernet example (not a perfect one I should accentuate again): why bother with blocking it's uptake when it is too fundamentally useful and enabling for a whole bunch of other innovation that builds on top.
You can’t (easily) make a standard go away but being a standard doesn’t stop anyone from making it illegal to use.
> It also cements the fact that the technology being standardized is simply too fundamental and likely ubiquitous
Why do you think everything with an ISO standard is even remotely fundamental? There is an ISO standard for M/MUMPS (https://www.iso.org/standard/29268.html, https://en.wikipedia.org/wiki/MUMPS, for example, but I wouldn’t call it fundamental. Some systems would break if MUMPS became illegal, but fundamental requires more, IMO.
> The risks aren’t theoretical. A new report found that DeepSeek, a Chinese AI firm, has been responsible for producing malicious code in roughly half the sensitive cybersecurity incidents analyzed on GitHub. If China is willing to leverage open software in ways that harm global security, why would we assume open-source hardware will be treated differently?
> A single compromised RISC-V chip in a power grid, data center or weapons system could hand Beijing a quiet path into critical infrastructure. The more these chips spread, the greater the odds a vulnerability becomes a weapon.
I think the concern here is more with the implementations (coming out of China) than the instruction set itself. Or perhaps if there is some Verilog/VHDL code out there with backdoors, and that then gets baked into chips.
> I think the concern here is more with the implementations (coming out of China) than the instruction set itself.
Yes that is the pretense, but what they actually want to block is RISC-V adoption.
It's a bit similar to car industry opposition to right to repair, they ran TV ads claiming dangers for safety and security if independent repair were allowed. Louis Rossmann did a series of videos on this.
In such scenarios, the assembly routines lend themselves to relatively easier manual scrutiny - given that they are smaller in size compared to the much larger higher level language code in the project.
It's the latter that really needs the compiler's assistance to help remove memory safety issues (it is much harder for humans given the code size and complexity order). The fact that that safe higher level language code is inter operating with inherently unsafe code (as per the Rust definitions) is absolutely OK.
Reaching parity with Linux's immense suite of device drivers is perhaps the single biggest hurdle.
That's one of the biggest reasons why alternative kernels either remain fringe or fail.
Initiatives such as NetBSD's Rump kernel but for Linux may provide a bridge to Linux's drivers but it's brittle. There's already LKL - the Linux Kernel Library project with similar aims but not much traction.
That's quite unlikely. What's more likely is the emergence of a better approach for incremental inclusion of Rust in the kernel. This policy is a decent stake in the ground.
Incremental is not going to work for someone who doesn't want to install any Rust stuff to compile their kernel or understand Rust to work in the kernel.
Possibly. What's more likely is that folks would want to ask why major corporations are willing to invest the dollars to commit to Rust and it's take on memory safety, at scale.
Once that's internalised, those 'someone's may either align or be the outliers that don't matter in the greater scheme.
Linux kernel work is being done by countless embedded outfits all around the globe. Rust is completely misaligned with the embedded skill set and attitude; there will be a clash and backlash. Embedded people don't want to be told, you can't shove that value obtained here into there because of some cockamamie language rule.
I assume you allude to Rust's borrow checker. If you are, your concern is misplaced: which is a common occurrence unfortunately when it comes to this topic. Note that most of the interaction with the borrow checker's rules would be tackled by the interfaces between Rust and C that are being incrementally added to the kernel. By the time the 'end users' (the embedded Linux device driver authors you allude to) are involved, all they are doing is using safe Rust wrappers for loads and stores to MMIO, as an example, where there is no fundamental interaction with the borrow checker (because those happen at another level in the call graph involved).
That said: To appreciate the value Rust provides there is going to be some experience driven knowledge gain needed but the efforts underway should help.
Arm has been enabling server/data-center class SoCs for a while now (eg Amazon Graviton et al). This is only going to pick up further (eg Apple Private Cloud Compute).
Also, there's nothing fundamentally stopping chiplet pick-up in traditional embedded domains. It's probably quite likely.
They have been "enabling" them but not designed the best of them(°), and I'm not sure how serious they are about the top end because their results are rather half-assed compared to Apple, AMD and Intel. As is, their bread and butter and main focus is still mobile and embedded chips.
(°) The best of them also seem to use barely any ARM standards except for the ISA itself
Arm's definitely trying to push on the laptop, tablet, desktop, and server markets. The fastest cluster on the top500 was arm for several years, most of the big clouds either have home grown arm servers (like graviton) or will soon.
Arm doesn't only do ISA. It essentially wrote the standards for the AMBA/AXI/ACE/CHI interconnect space. Standardizing chip-to-chip interconnects is very much in Arm's interests. It is a double edged sword though since Chiplets will likely enable fine grained modularity allowing IP from other vendors to be stitched around Arm (eg RISC-V IOMMU instead of Arm SMMUv3 etc).
A dual ISA decoder with with fuse-off options will likely have unwelcome power-perf-area and yield consequences.