linux-m68k.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Gerhard Pircher <gerhard_pircher@gmx.net>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Sparc kernel list <sparclinux@vger.kernel.org>,
	Linux-sh list <linux-sh@vger.kernel.org>
Subject: Re: Old platforms: bring out your dead
Date: Tue, 12 Jan 2021 23:46:04 +0100	[thread overview]
Message-ID: <CACRpkda4E2NwNw29J7x5gehtqn_m3M_Z2dHpc7xRgvb0b-p22A@mail.gmail.com> (raw)
In-Reply-To: <cb5a2e11-d423-96ec-3d43-3568a109e37f@physik.fu-berlin.de>

On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:

> Yeah, I have the same impression that's the strong commercial interest pushes
> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
> they're motivated by corporate decisions.
>
> There has to be a healthy balance between hobbyist and commercial use. I understand
> that from a commercial point of view, it doesn't make much sense to run Linux
> on a 30-year-old computer. But it's a hobbyist project for many people and hacking
> Linux stuff for these old machines has a very entertaining and educational factor.

This is actually one of the most interesting things written in this discussion.

I have both revamped and deleted subarchitectures in the ARM tree. We
never deleted anyone's pet project *unless* they were clearly unwilling to
work on it (such as simply testning new patches) and agreed that it will
not go on.

At multiple occasions I actually found it easier to fix stuff than
delete it, both because it is a nicer thing to do and because it
simply creates less social problems, often to the point that the time
(man hours) spent trying to solve the resulting social problems from
deleting a platform would be longer than the time spent actually acquiring
the physical platform and fixing it.

Corporate entities can be a bit deletionist (using Wikipedia terminology)
and as in this thread there is always a strong inclusionist stance pushing
back to that.

The explanation is in my mind very simply that running Linux
on a 35-yo or so Amiga, Atari or Apollo Workstation is pretty impressive and
fun. And I think that fits Mr. Torvalds own sociological-or-something
explanation in the autobiographical "Just for fun" as to why to write it
in the first place. And we are very protective of that quality of the
kernel. (At least I am.)

That said there are a three things that people should really be doing if they
want to keep their pet archs/subarchs around as good community
members, and they are in essence to:

1. Test and review/ack patches that others make

2. Migrate existing drivers to newly appeared and
    appropriate subsystems (I think there are some hacky heartbeat LED
    drivers down in arch/* for example) there is also the feature matrix
    core maintainers like and which appears if you type
    Documentation/features/list-arch.sh <archname>
    would be nice if you work on them if you can support them!
    Or at least take a look.

3. Migrate old systems to use the
   contemporary hardware descriptions (such as device tree or ACPI)
   because it makes things so much easier to maintain. Some
   upfront work, but a great win for everyone. Especially for
   subsystem maintainers.

And if your arch uses highmem then please get rid of highmem. I'm
trying to do this a bit right now for ARM let's see how it goes.

I understand that for some maintainers time is a factor and this list
feels stressful. I'd say relax, but it'd be nice if you have a TODO that
you cross items off of.

Just my €0.01
Linus Walleij

  reply	other threads:[~2021-01-12 22:46 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAK8P3a2VW8T+yYUG1pn1yR-5eU4jJXe1+M_ot6DAvfr2KyXCzQ@mail.gmail.com>
2021-01-10 17:35 ` Old platforms: bring out your dead John Paul Adrian Glaubitz
2021-01-10 21:46   ` Sam Ravnborg
2021-01-11  8:05     ` John Paul Adrian Glaubitz
2021-01-11 14:55       ` chase rayfield
2021-01-12  0:26         ` Rob Landley
2021-01-12  0:50           ` chase rayfield
2021-01-12 14:37         ` John Paul Adrian Glaubitz
2021-01-11 18:09     ` Rob Landley
2021-01-11 15:04   ` Gerhard Pircher
2021-01-12 14:44     ` John Paul Adrian Glaubitz
2021-01-12 22:46       ` Linus Walleij [this message]
2021-01-13  8:09         ` Rob Landley
2021-01-13  8:21           ` Geert Uytterhoeven
2021-01-13 13:25             ` Rob Landley
2021-01-13 12:02           ` Andy Shevchenko
2021-01-13  8:15         ` Geert Uytterhoeven
2021-01-13 10:39         ` Arnd Bergmann
2021-01-14  3:54           ` New platforms: bring out your dead, was " Finn Thain
2021-01-14  9:41         ` John Paul Adrian Glaubitz
2021-01-14  9:48           ` Geert Uytterhoeven
2021-01-14 21:21           ` Arnd Bergmann
2021-01-14 22:54             ` Undesirable code, was Re: Old platforms etc Finn Thain
2021-01-14 23:09             ` Old platforms: bring out your dead Max Filippov
2021-01-15  8:31               ` Arnd Bergmann
2021-01-13  0:12       ` Old platforms never die, was " Finn Thain
2021-01-16  6:54         ` Rob Landley
2021-01-16 23:22           ` Finn Thain
2021-01-13 11:47       ` Andy Shevchenko
     [not found] <CAFr9PX=BV1YFcO_GQWsW3XEo8nndjUwArzW5Fg1fnWzt8fiwGw@mail.gmail.com>
2021-01-11  9:15 ` John Paul Adrian Glaubitz
2021-01-11  9:20   ` Geert Uytterhoeven
2021-01-11  9:26     ` John Paul Adrian Glaubitz
2021-01-11  9:36       ` Geert Uytterhoeven
2021-01-11  9:50         ` Greg Ungerer
2021-01-11  9:42   ` Daniel Palmer

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=CACRpkda4E2NwNw29J7x5gehtqn_m3M_Z2dHpc7xRgvb0b-p22A@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=arnd@arndb.de \
    --cc=gerhard_pircher@gmx.net \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=sparclinux@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).