Message-ID: <20251001183321.GA2760@quark>
Date: Wed, 1 Oct 2025 11:33:21 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ben Dooks <ben.dooks@...ethink.co.uk>, Paul Walmsley <pjw@...nel.org>,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] RISC-V updates for v6.18-rc1

On Tue, Sep 30, 2025 at 04:53:24PM -0700, Linus Torvalds wrote:
> On Tue, 30 Sept 2025 at 09:04, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > Oh Christ. Is somebody seriously working on BE support in 2025?
> 
> 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.

+1.  Please, let's not do big endian RISC-V kernels :(

This mistake was made for arm64, it's finally getting fixed.
See https://lore.kernel.org/r/20250919184025.15416-1-will@kernel.org/
Let's not make the same mistake again.

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.  (I don't really care enough to fix it, TBH.)

I recently added arm64 big endian to my own testing matrix.  But I look
forward to dropping that, as well as *not* having to start testing on
RISC-V big endian too...

Of course, that's just one example from my own experience.  There's a
lot more that CONFIG_CPU_BIG_ENDIAN creates problems for.

- Eric

Powered by blists - more mailing lists