Message-ID: <CAHk-=wji-hEV1U1x92TLsrPbpSPqDD7Cgv2YwzeL-mMbM7iaRA@mail.gmail.com>
Date: Wed, 1 Oct 2025 12:39:19 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Conor Dooley <conor@...nel.org>
Cc: Ben Dooks <ben.dooks@...ethink.co.uk>, 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 Wed, 1 Oct 2025 at 12:03, Conor Dooley <conor@...nel.org> wrote:
>
> None of that was really done as a deliberate attempt to add support
> for BE, in case that assuages concerns you might have about the taste
> of the arch maintainers..

Thanks, it does.

As others have mentioned, the arm64 support ends up being problematic
and people are actively trying to remove it.

BE is dead. There is one good reason to support it - legacy
architectures designed and implemented back in the days when it wasn't
dead _yet_.

But it's a huge pain, and the world has moved on. Dealing with BE with
any half-way modern infrastructure is a dead end, since things like
PCIe are all fundamentally little-endian.

If somebody really wants to create bad hardware in this day and age,
please do make it big-endian, and also add the following very
traditional features for sh*t-for-brains hardware:

 - virtually tagged caches

   You can't really claim to be worst-of-the-worst without virtually
tagged caches.

  Tears of joy as you debug cache alias issues and of flushing caches
on context switches.

 - only do aligned memory accesses

   Bonus point for not even faulting, and just loading and storing
garbage instead.

 - expose your pipeline details in the ISA

   Delayed branch slots or explicit instruction grouping is a great
way to show that you eat crayons for breakfast before you start
designing your hardware platform

 - extended memory windows

   It was good enough for 8-bit machines in order to address more
memory, and became a HIGHMEM.SYS staple in the DOS world, and then got
taken up by both x86 and arm in their 32-bit days as HIGHMEM support.

   It has decades of history, and an architecture cannot be called
truly awful if it doesn't support some kind of HIGHMEM crap.

 - register windows. It's like extended memory, but for your registers!

   Please make sure to also have hardware support for filling and
spilling them, but make it limited enough that system software has to
deal with faults at critical times. Nesting exceptions is joyful!

   Bonus points if they are rotating and overflowing them silently
just corrupts data. Keep those users on their toes!

 - in fact, require software fallbacks for pretty much anything unusual.

   TLB fills? They might only happen every ten or twenty instructions,
so make them fault to some software implementation to really show your
mad hardware skillz.

   denormals or any other FP precision issues? No, no, don't waste
hardware on getting it right, software people *LOVE* to clean up after
you.

   Remember: your mom picked up your dirty laundry from your floor,
and software people are like the super-moms of the world.

 - make exceptions asynchronous.

   That's another great way to make sure people stay on their toes.
Make sure machine check exceptions can happen in any context, so that
you are guaranteed to have a dead machine any time anything goes
wrong.

   But you should also take the non-maskability of NMI to heart, and
make sure that software cannot possibly write code that is truly
atomic. Because the NM is NMI is what makes it great!

   Floating point! Make sure that the special case you don't deal with
in hardware are also delayed so that the software people have extra
joy in trying to figure out just WTF happened. See the previous entry:
they live for that stuff.

I'm sure I've forgotten many other points. And I'm sure that hardware
people will figure it out!

              Linus

Powered by blists - more mailing lists