Re: [GIT PULL] RISC-V updates for v6.18-rc1

[Ben Dooks]

On 02/10/2025 16:06, Olof Johansson wrote:
> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx/

Sorry, didn't see that and would have replied if I had.


--
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html