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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3c9d9f92-aaf8-4d4d-a2d9-8d6a410edc30@codethink.co.uk>
Date: Thu, 2 Oct 2025 13:48:47 +0100
From: Ben Dooks <ben.dooks@...ethink.co.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: 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 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.

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/).

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).

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.

> 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.

> Really.
> 
>               Linus
> 

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

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