Re: [PATCH 03/13] ARM: remove riscpc

From: Linus Walleij

Date: Fri Sep 11 2026 - 09:52:01 EST


On Fri, Sep 11, 2026 at 3:26 PM Bart Van Assche <bvanassche@xxxxxxx> wrote:
> On 9/11/26 2:07 AM, Linus Walleij wrote:

> > The community has a built in tension around this:
> >
> > - One camp that are enthusiast like yourself. That kind of people
> > are running the show inside arch/m68k on Amigas and Ataris.
> >
> > - One camp who get their paycheck from present day companies
> > and constantly on top of the latest technology. As can be
> > seen Qualcomm just taped out a brand new ARMv7 SoC
> > named Kuno, for example.
> >
> > As you can see this leads to a bit of tension.
>
> That summary looks incomplete to me. Every time a kernel API is modified
> that is used by the RiscPC code, the RiscPC code has to be modified too.
> Removing the RiscPC code makes modifying kernel APIs easier. A recent
> example is available here: "[PATCH v5] scsi: core: Drop
> Scsi_Host.default_lock"
> (https://lore.kernel.org/linux-scsi/20260831095821.3486994-1-john.g.garry@xxxxxxxxxx/).

Yes that is development churn, but this is the same whether the hardware
supported is old or brand new and doesn't really answer the question
whether it is to be supported or not.

That line of reasoning will always require a supportive hypothesis such as:

- We don't want to support stuff that is old (deprecation and deletionist
stance, I don't want to hear yesterdays news)

- We don't want to support stuff that has very few users (utilitarism,
basically,
the biggest common good for the biggest number of people take
precedence)

This is implicit in many statements people make about this. What entusiasts
ask is a completely different question:

- Is this fun (for me/us), makes me feel good to work on etc.

NB: personally I don't take a clear stance here, I mostly want to break apart
the argument and clarify what it is all about.

Yours,
Linus Walleij