[mort96]

Linus hates introducing a ton of complexity and opportunity for bugs for no upside. Pre-emptively adding runtime endianness switching to RISC-V when there's not even market demand for it 100% falls into that category. Adding runtime endianness switching to the RISC-V ISA also falls into that category.

Supporting big endian for big-endian-only CPUs does not fall into that category.

[zamalek]

The first line in the email that I linked is pretty unambiguous:

> Oh Christ. Is somebody seriously working on BE support in 2025?

Followed by Eric:

> And as someone who works on optimized crypto and CRC code, the arm64 big endian kernel support has always been really problematic. It's rarely tested, and code that produces incorrect outputs on arm64 big endian regularly gets committed and released. It sometimes gets fixed, but not always; currently the arm64 SM3 and SM4 code produces incorrect outputs on big endian in mainline

BE support is unambiguously best-effort (which is none in some cases).

No, the Kernel does not take BE seriously. Not sure why I have to quote from the mailing list when the URL was a significant portion of my comment text - it directly contradicts your assertion on multiple fronts.

[mort96]

That's about someone adding BE support to an architecture which previously doesn't have it and therefore has no need for it. If you improve BE support in the kernel in order to fix or improve something on a supported BE-only architecture, I guarantee that Linus would have no qualms about it.

BE support in ARM is poor because ARM is primarily a LE architecture and almost nobody needs ARM BE.

[zamalek]

So the existing crypto bugs that nobody is bothered with are about _adding_ support?