Message-ID: <eed8c89b-eede-4595-b512-424749fec6ea@codethink.co.uk>
Date: Thu, 2 Oct 2025 16:22:04 +0100
From: Ben Dooks <ben.dooks@...ethink.co.uk>
To: Olof Johansson <olof@...om.net>
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 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@...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/

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

Powered by blists - more mailing lists