Message-ID: <aN8qnSfzFjdovsjn@yury>
Date: Thu, 2 Oct 2025 21:45:01 -0400
From: Yury Norov <yury.norov@...il.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	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 Wed, Oct 01, 2025 at 11:33:21AM -0700, Eric Biggers wrote:
> 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.

+2. I maintain bitops, and I routinely have to take endianess into
account.

I just realized that I didn't run BE kernels for at least 3 years, and
didn't ask my contributors to do it for even more. The last BE-related
fix for bitops I can recall is dated back to 2020:

81c4f4d924d5d009 ("lib: fix bitmap_parse() on 64-bit big endian archs").

Nobody ever reported BE bugs for the new code.

Maintenance burden is not just a word. Things are getting really tricky
when you have to keep BE compatibility in mind. And it's a special
torture to run an old arm or sparc VM in BE-32 against modern kernels.

But what really important is that dropping BE support will make codebase
overall cleaner and better.

Thanks,
Yury

Powered by blists - more mailing lists