""WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V""
Linus send that to #LKML a few hours ago, after somebody asked if some of the big-endian work will make it into #Linux 6.18.
For the full thread, see: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%2BHfB4n6Wj6zM5H5EghUMfpXSCzyQVSfA@mail.gmail.com/t/#mce138059dc56014643bbda330810183031ef5c06
There he calls the reasons documented on riscv.org as "craziness" and insane:
""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.""
@kernellogger for those wondering, risc-v is an #OpenSource #cpu thingy. So #linux naturally is a kernel that would be suited for it. Why it has taken so long I don't know?
https://en.m.wikipedia.org/wiki/RISC-V
risc-v Linux is maturing
https://riscv.org/blog/2025/07/risc-v-upstreaming/
@kernellogger
Omg. When I first read the "little endian is a problem for IP" line, they were thinking about VAX.
Seriously? Complaining about byteswapping in 2025?
@mbpaz well, you know how this world is: there is always somebody somewhere that for good or bad reasons wants to do something (and even has the money to do so), that other deem crazy; sometimes it really is crazy, but occasionally it turns out to be something greatβ¦[
[Edit to clarify] I definitely *not* trying to imply here that the BE support will likely turn out to fall into the "great" category!
@kernellogger already rephrased that. I was thinking while writing.
@hanscees this sub-thread now looks really confusing; I'll not delete my earlier reply to work against that.
@kernellogger @mbpaz Sure. But in 2025, anyone trying to ADD big endian to an existing architecture has a pretty high bar to clear in order to prove that it's going to be "great".
@gfxstrand @mbpaz s/little/big/ I suppose.
But sure. I was not trying to implicate that I think this falls into the "great" category.
Guess it could be read that way. Will edit the toot to avoid that.
@kernellogger Edited. And don't worry about it. I don't think you meant to imply it's great.
I do think that they have a pretty high bar to clear before asking the kernel to carry a bunch of big endian code, though.
@kernellogger I've seen network vendors which have unportable bigendian code which they've not got the stomach to try and port to little endian. .
@penguin42 π
Nevertheless "create a new BE hw arch as well as everything else needed for it (e.g. the OS)" to avoid some of that porting pain sounds like the wrong answer to me; but well, maybe it's bad enough for them to make them pay big money (but for how long?)β¦
@kernellogger Perhaps it's the type of thinking if your supply of PPC chips just dried up.
@kernellogger great, now can we ban riscv nommu as well? Cc @ljs
@kernellogger I'd have thought even BCD mode would be more useful than big endian 8)
@etchedpixels @kernellogger "Feature request: support BCD-encoded pointers"
If it's open season, I want a shot.
@mbpaz @etchedpixels @kernellogger ...with variable lengths, so we can avoid any future address limit issues!
@hanscees @kernellogger risc-v is open standard ISA not "opensource cpu".
Sure, anyone can play with making cpus based on this architecture. Without paying anyone else for any kind of licence.
But that does not mean that it is opensource cpu. IIRC most of risc-v designs are closed solutions which you may license from their designers. Or buy ready SoC.
And, IMHO, the main reason vendors go risc-v is "you do not have to pay Arm nor Intel/AMD".
@kernellogger @penguin42 I like the fact that even on aarch64 going big endian is considered weird.
Good that it is now "depends on BROKEN"
@hrw @kernellogger I find it helps if you talk about 'wrong endian' - alas the S390 folks seem to object.
@penguin42 @kernellogger "wrong endian" may suggest "middle endian".
And that's sounds sick.
@palmer @kernellogger @ljs I already know hch would be against :/
@hrw @kernellogger Alas it existed: https://en.wikipedia.org/wiki/Endianness#Middle-endian
@palmer @kernellogger @ljs interesting, previously when Lorenzo suggested the removal, hch said something about upcoming products based on it
@vbabka @palmer @kernellogger he was absolutely adamant nommu was brilliant and we have a perfectly functional nommu impl (lol no)
Anyway he was citing arm32 as a motivator.
And now we end up in a world where I by accident co maintain this btw
@palmer @kernellogger @vbabka well this was more to avoid too many further horrors:p