Message-ID: <aN6U8NtIfqd-fowQ@chonkvm.lixom.net>
Date: Thu, 2 Oct 2025 08:06:24 -0700
From: Olof Johansson <olof@...om.net>
To: Ben Dooks <ben.dooks@...ethink.co.uk>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	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 Thu, Oct 02, 2025 at 01:48:47PM +0100, Ben Dooks wrote:
> On 30/09/2025 17:04, Linus Torvalds wrote:
> > On Tue, 30 Sept 2025 at 00:25, Ben Dooks <ben.dooks@...ethink.co.uk> wrote:
> > > 
> > > Is there any chance some of the big-endian work we did is getting in
> > > for this round?
> > 
> > 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.
> 
> We first tackled big-endian support on ARM32 nearly 15 years ago, and
> drawing on that experience, we saw value in doing the same work on RISC-V as
> a way for newer engineers to gain hands-on experience contributing in the
> open.

Getting new people going is great, but if you were around for that
one you also know just how little usage it saw over time -- the ARMv8
big endian enablment has been on (minimal) life support with just some
downstream usage in vendor kernels. Adding the burden for everybody to
maintain this work forever is the flip side of the coin here.

> Now we’re starting to see commercial cores on the horizon that will have the
> ability to be endian configured at run-time. For example, MIPS (the company
> not the ISA) has announced they will be producing cores with configurable
> endian (https://mips.com/products/hardware/i8500/).

MIPS has been doing some not so awesome things to the RISC-V architecture
in the last year or so. They've published patchsets that make it seem
like that they seem to have taken some old MIPS designs and done the
bare minimal conversion over to RISC-V, since they need their own weird
system peripherals and hooks. Again, with the burden for everybody to
maintain because their hardware engineers couldn't bother to develop a
full proper RISC-V core.

While I'm not happy with the lack of upstreaming from the (mostly
Chinese) SoC vendors, and we should be encouraging more of them to
contribute directly, MIPS seems to be making choices that might have
long term burden for all of us. So far the slope is slippery on the
system side, but needing to worry about BE support seems to be stepping
over the line for me without some obvious clear use cases that make sense.

> Note some of the patches we are proposing also make the code better, such as
> swapping .word for .insn.
> 
> > RISC-V is enough of a mess with the millions of silly configuration
> > issues already. Don't make it even worse.
> 
> This feels like the price you pay for making a flexible and free ecosystem
> to build cores. There is no single authority making you use every feature
> that might be specified (although Ubuntu's choice to move forward with RVA32
> for future is a current pain for anyone who already has purchased hardware).

Just because the ecosystem is flexible, doesn't mean you need to encourage
and support everything that gets built.

> See initial reply for comment on MIPS. We also don't think this a huge
> change and given most projects we worked through had few (if any) issues
> with building big endian, we thought it was worth having an attempt at this.

To me, it's not about the initial effort but about the (forever) work of
keeping it going without regressions. Now everybody will need BE CI, etc.

> > Tell people to just talk to their therapists instead.  That's *much*
> > more productive.
> 
> 
> Thanks, but that isn't helpful and is just making the kernel look more
> toxic. I am however going to wear the "I got ranted at by Linus and
> survived" tag with pride.

Hey Ben -- you posted a *RFC* of the patches in December 2024. I replied
to those. So did Palmer. With exactly these concerns. Did we get a
response from you? Nope.

So, seems like Linus has better success being impolite. That's a bummer.

For the RFC thread, see https://lore.kernel.org/all/Z2XLS2HX2KqBJW6U@chonkvm.lixom.net/


-Olof

Powered by blists - more mailing lists