LKML Archive on lore.kernel.org
 help / color / Atom feed
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: Linus Walleij <linus.walleij@linaro.org>
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: Thu, 14 Jan 2021 10:41:33 +0100
Message-ID: <1be37673-db0e-f09d-68c8-f929be4019ab@physik.fu-berlin.de> (raw)
In-Reply-To: <CACRpkda4E2NwNw29J7x5gehtqn_m3M_Z2dHpc7xRgvb0b-p22A@mail.gmail.com>

Hello Linus!

On 1/12/21 11:46 PM, Linus Walleij wrote:
> 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.

I'm not arguing this. This was more about killing (sub-)architectures because they
haven't seen git activity for a long time which I think is poor metric to determine
whether a port is dead or not. And reading through the other answers in this thread,
it seems I'm not alone with this stance.

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

Good to hear.

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

It's an obvious conflict.

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

I'm happy to hear that. For me personally, it also has a very educational value
as the non-mainstream platforms such as m68k offer more places of code to hack
on for adding features such as SECCOMP which are still missing there.

There are usually enough people working on architectures such as x86 and ARM,
so there is not much room for hobbyist activities. Also, you risk making much
more people upset if you break something.

> 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

I am already doing that as much as I can for various architectures such as ia64,
m68k, SH and POWER, SPARC although I need to ramp up my activity a bit more. I have
also now added myself for the linux-alpha mailing list to test and ack patches for
the Alpha architecture as well.

I have to admit I have quite a number of pet architectures but that's because I'm
co-maintaining these architectures in Debian Ports with regular releases of Debian
installation images for these targets:

> https://cdimage.debian.org/cdimage/ports/snapshots/

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

Thanks for the pointer. I'm not so much active in kernel development itself yet, but
I'm also trying to be more active. Although the kernel is not the only project that
sometimes needs attention for these pet architectures. We're also confronted with
deprecation problem in problems such as GCC although we recently saved the m68k
(and VAX) backends in GCC with the help of a Bountysource campaign. The AVR backend
is also backed by such a campaign and currently being worked on.

We are even getting an m68k backend for LLVM hopefully soonish, so we will even be able
to build the Linux kernel for m68k with clang :-).

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

There is such a patch set for arch/sh to add device tree support, but so far it has not
been merged yet, unfortunately. Apparently, it causes some regression on LANDISK devices
according to Rich Felker.

Maybe we can finally get it merged this year:

> https://lore.kernel.org/patchwork/cover/693910/

Since Geert also has a LANDISK SH device now for testing, he might be able to help.

Oh, and if anyone else is interested in helping with the SH port, I'm happy to send
them a free LANDISK or NextVoD SuperH device - the latter has a 450 MHz ST-40
CPU and 256 MB RAM.

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

Is there a list of architectures which still need highmem?

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

Thanks for the kind words. I appreciate the input.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


  parent reply index

Thread overview: 121+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08 22:55 Arnd Bergmann
2021-01-08 23:32 ` Steven Rostedt
2021-01-09 22:04   ` Arnd Bergmann
2021-01-08 23:44 ` Thomas Bogendoerfer
2021-01-09  0:16 ` Linus Walleij
2021-01-09 17:32   ` Florian Fainelli
2021-01-09 21:59   ` Arnd Bergmann
2021-01-09  5:56 ` Willy Tarreau
2021-01-09 21:52   ` Arnd Bergmann
2021-01-10  6:21     ` Willy Tarreau
2021-01-10 10:44       ` Russell King - ARM Linux admin
2021-01-11  9:50     ` David Laight
2021-01-13 10:27       ` Andy Shevchenko
2021-01-13 12:02         ` Linus Walleij
2021-01-13 12:17           ` Andy Shevchenko
2021-01-13 12:21             ` Andy Shevchenko
2021-01-15  0:03               ` Bernd Petrovitsch
2021-01-15  0:24                 ` William Breathitt Gray
2021-01-15  8:59                   ` David Laight
2021-01-13 12:30           ` William Breathitt Gray
2021-01-13 12:56             ` William Breathitt Gray
2021-01-13 13:44           ` Arnd Bergmann
2021-02-04 21:01         ` Pavel Machek
2021-02-05  9:13           ` David Laight
2021-02-05  9:29             ` Pavel Machek
2021-01-09 17:34 ` Florian Fainelli
2021-01-09 21:18   ` Arnd Bergmann
2021-01-09 17:43 ` Russell King - ARM Linux admin
2021-01-09 21:34   ` Arnd Bergmann
2021-01-11 20:09     ` Russell King - ARM Linux admin
2021-01-09 20:19 ` Baruch Siach
2021-01-09 21:19   ` Arnd Bergmann
     [not found] ` <67171E13-6786-4B44-A8C2-3302963B055F@gmail.com>
2021-01-09 22:20   ` Arnd Bergmann
2021-01-10 18:12     ` Fabian Vogt
2021-01-10 19:20       ` Arnd Bergmann
2021-01-10 21:33       ` Linus Walleij
2021-01-11  0:33         ` Russell King - ARM Linux admin
2021-01-11 12:32           ` Arnd Bergmann
2021-01-11 12:36             ` Russell King - ARM Linux admin
2021-01-09 23:12 ` Andrew Lunn
2021-01-10  8:45   ` Arnd Bergmann
2021-01-10 16:46     ` Andrew Lunn
2021-01-10 17:27       ` Arnd Bergmann
2021-01-10 19:51         ` Andrew Lunn
2021-01-10 15:51 ` Neil Armstrong
2021-01-10 15:56   ` Arnd Bergmann
2021-01-10 17:35 ` 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
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 [this message]
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
2021-01-11  1:39 ` Daniel Palmer
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
2021-01-11 10:13   ` Arnd Bergmann
2021-01-11  8:19 ` Geert Uytterhoeven
2021-01-11  8:59   ` Arnd Bergmann
2021-01-11  9:16     ` Geert Uytterhoeven
2021-01-11 10:28       ` Geert Uytterhoeven
2021-01-11 10:37         ` Arnd Bergmann
2021-01-11  9:40     ` Thomas Bogendoerfer
2021-01-11 10:34       ` Arnd Bergmann
2021-01-11  8:40 ` efm32 is dead [Was: Old platforms: bring out your dead] Uwe Kleine-König
2021-01-11 11:10 ` Old platforms: bring out your dead Viresh Kumar
2021-01-11 19:59   ` Arnd Bergmann
2021-01-11 21:15     ` Mattias Wallin
2021-01-11 21:47       ` Arnd Bergmann
2021-01-11 13:13 ` Marc Gonzalez
2021-01-11 17:29   ` Måns Rullgård
2021-01-11 21:50     ` Arnd Bergmann
2021-01-12  8:23       ` Marc Gonzalez
2021-01-11 14:22 ` Mark Salter
2021-01-11 15:00   ` Arnd Bergmann
2021-01-11 14:44 ` Alexander Shiyan
2021-01-11 14:58   ` Arnd Bergmann
2021-01-11 16:23 ` Sylvain Lemieux
2021-01-11 22:17   ` Alexandre Belloni
2021-01-11 19:58 ` Thomas Petazzoni
2021-01-11 20:10   ` Arnd Bergmann
2021-01-11 20:25 ` Song Bao Hua (Barry Song)
2021-01-12  8:41   ` Marc Gonzalez
2021-01-13 10:30 ` Andy Shevchenko
2021-01-13 11:02   ` Arnd Bergmann
2021-01-13 16:14 ` [v2] " Arnd Bergmann
2021-01-13 19:00   ` Krzysztof Hałasa
2021-01-14  8:51     ` Arnd Bergmann
2021-01-15  7:08   ` Wei Xu
2021-01-15  9:26     ` Arnd Bergmann
2021-01-15 11:09       ` Leizhen (ThunderTown)
2021-01-15 12:04         ` Arnd Bergmann
2021-01-18 10:46           ` Wei Xu
2021-01-13 22:27 ` Richard Z
2021-02-05 13:37 ` Alexander Lobakin
2021-01-12  2:05 tedheadster

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=1be37673-db0e-f09d-68c8-f929be4019ab@physik.fu-berlin.de \
    --to=glaubitz@physik.fu-berlin.de \
    --cc=arnd@arndb.de \
    --cc=gerhard_pircher@gmx.net \
    --cc=linus.walleij@linaro.org \
    --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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git