Linus Torvalds has come out strong against proposed support for RISC-V big endian capabilities within the Linux kernel.
In response to a mailing list comment whether RISC-V big endian “BE” patches being worked on would be able to make it for this current Linux kernel cycle. Linus Torvalds initially wrote:
“Oh Christ. Is somebody seriously working on BE support in 2025?
WHY?
Seriously, that sounds like just *stupid*. Is there some actual real reason for this, or is it more of the “RISC-V is used in academic design classes and so people just want to do endianness for academic reasons”?
Because I’d be more than happy to just draw a line in the sand and say “New endianness problems are somebody ELSES problem”, and tell people to stop being silly.
Let’s not complicate things for no good reason. And there is *NO* reason to add new endianness.
RISC-V is enough of a mess with the millions of silly configuration issues already. Don’t make it even worse.
Tell people to just talk to their therapists instead. That’s *much* more productive.”
Valid arguments raised by Linus Torvalds.
Linus Torvalds further added:
“Ok, I just googled this, and I am putting my foot down:
WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V
The documented “reasoning” for that craziness is too stupid for words, but since riscv.org did put it in words, I’ll just quote those words here:
“There are still applications where the way data is stored matters, such as the protocols that move data across the Internet, which are defined as big-endian. So when a little-endian system needs to inspect or modify a network packet, it has to swap the big-endian values to little-endian and back, a process that can take as many as 10-20 instructions on a RISC-V target which doesn’t implement the Zbb extension”
In other words, it is suggesting that RISC-V add a big-endian mode due to
(a) internet protocols – where byte swapping is not an issue
(b) using “some RISC-V implementations don’t do the existing Zbb extension” as an excuse
This is plain insanity. First off, even if byte swapping was a real cost for networking – it’s not, the real costs tend to be all in memory subsystems – just implement the damn Zbb extension.
Don’t go “we’re too incompetent to implement Zbb, so we’re now asking that EVERYBODY ELSE feel the pain of a much *worse* extension and fragmenting RISC-V further”.
I’m hoping this is some April fools joke, but that page is dated “March 10, 2025”. Close, but not close enough.
This is the kind of silly stuff that just makes RISC-V look bad.
Ben – I’m afraid that that page has “further reading” pointing to codethink.
I see some CONFIG_CPU_BIG_ENDIAN has already made it in, but this needs to stop.
The mainline kernel is for mainline development. Not for random experiments that make the world a worse place.
And yes, we’re open source, and that very much means that anybody is more than welcome to try to prove me wrong.
If it turns out that BE RISC-V becomes a real thing that is relevant and actually finds a place in the RISC-V ecosystem, then _of_course_ we should support it at that point in the mainline kernel.
But I really do think that it actually makes RISC-V only worse, and that we should *not* actively help the fragmentation.”
So don’t look for RISC-V BE happening with the mainline Linux kernel.
