mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ben Dooks <ben.dooks@codethink.co.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Walmsley <pjw@kernel.org>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] RISC-V updates for v6.18-rc1
Date: Thu, 2 Oct 2025 13:48:47 +0100	[thread overview]
Message-ID: <3c9d9f92-aaf8-4d4d-a2d9-8d6a410edc30@codethink.co.uk> (raw)
In-Reply-To: <CAHk-=wgfpswvq0TypePyjv3dofO5YaUC_fSd_MjzY7jogCUnCg@mail.gmail.com>

On 30/09/2025 17:04, Linus Torvalds wrote:
> On Tue, 30 Sept 2025 at 00:25, Ben Dooks <ben.dooks@codethink.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

  parent reply	other threads:[~2025-10-02 12:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-29  8:00 Paul Walmsley
2025-09-30  2:54 ` pr-tracker-bot
2025-09-30  7:25 ` Ben Dooks
2025-09-30 16:04   ` Linus Torvalds
2025-09-30 23:53     ` Linus Torvalds
2025-10-01 18:33       ` Eric Biggers
2025-10-03  1:45         ` Yury Norov
2025-10-01 19:02       ` Conor Dooley
2025-10-01 19:39         ` Linus Torvalds
2025-10-02 12:48     ` Ben Dooks [this message]
2025-10-02 15:06       ` Olof Johansson
2025-10-02 15:22         ` Ben Dooks
2025-10-07 23:43         ` Maciej W. Rozycki
2025-10-20 23:31           ` Paul Walmsley
2025-10-02 18:08       ` Theodore Ts'o
2025-10-11  8:38 ` Yao Zi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3c9d9f92-aaf8-4d4d-a2d9-8d6a410edc30@codethink.co.uk \
    --to=ben.dooks@codethink.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=pjw@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®