Kernel Devs Considering Removal of some old CPU support

[GreenNeonWhale]

I just read that there is talk of removal of kernel support for some old cpus in kernels after 5.10. It seems that some PowerPC models past the 601 have been mentioned.
I still use PPC32 boxes to run Linux. In fact, my current router is a B&W G3. I've always been VERY appreciative of Linux support for older machines. I keeps them useful. Plus, occasionally, they can have some small advantages like these:

• No management engine
  
• Firmware that cannot be changed without first booting the machine while holding down the physical "Programmer's Button". (All the New World PowerPC Desktop Macs have this from B&W -> Quicksilver, if memory serves.)
  
• Low Cost -- old, used computers can be VERY cheap.

I'd like to weigh in on this, but I DO NOT want to waste the kernel developers time. Should we, PowerPC32 Linux users, be worried? Would it be appropriate for a regular user to weigh in on this issue? Should I/We email them about this?

Here are the two relevant links:
https://www.phoronix.com/scan.php?page=news_item&px=2021-Linux-Drop-Old-CPUs
https://lore.kernel.org/lkml/CAK8P3a2VW8T+yYUG1pn1yR-5eU4jJXe1+M_ot6DAvfr2KyXCzQ@mail.gmail.com/

[Hu]

I read the cited lore thread, and a few of the responses. In the messages I read, it does not appear that anyone is proposing to remove the PPC support you mention. As I read the cited message, powerpc are in the section marked I'm not doing anything about those unless the maintainers would like me to. So unless a maintainer speaks up somewhere in the thread to ask that those be dropped, they should be fine. If you are worried, you could start by contacting a PPC-specific kernel mailing list. State that you saw the lore thread (and link to it for their convenience). State the models of CPU you use and are concerned about. State what, if any, contribution you are prepared to make to keeping them alive: timely testing of changes; submission of fixes if it breaks; interest in becoming a contributor; etc. For some projects, particularly with rarer hardware, just volunteering to timely test changes may be enough to convince a maintainer to keep the platform alive.

[GreenNeonWhale]

Hu,

Thanks for your reply and taking the time to look into the matter. You clarified the issue for me concerning PPC32 post 601.

Unfortunately, my coding skills are EXCEEDINGLY limited. So it would be a while before I could be a help in that department. However, I do have a variety of PPC32 Apple hardware available to me, as well as some modest Linux SysAdmin skills, and hardware teching skills. I could do testing assistance in the near future, as well as provide machines via remote login to developers, and be the "hands". This is something that I've been considering doing anyway. I'm going to make a point of looking into this further soon.

I'd welcome any input on where to initiate contact if someone knows right off the top of their head. However, only if its a 30 second reply. Otherwise, I can figure it out on my own. As before, I don't want to waste anyone's time.

Thanks Again!

[Hu]

I don't know, but if it were me, I would start by inspecting the MAINTAINERS file in the kernel source tree. Looking in that file, linuxppc-dev@lists.ozlabs.org shows up frequently, and by its name, seems like a plausible starting place. If it is not the right place, its regulars might know where you should go instead.

[GreenNeonWhale]

Hu,

Thanks for the starting point.
Once I get my ducks in a row, which shouldn't take too long, I'm going to get into this.

[schwarzygesetzlos]

I've been filing ppc32/ppc64 bugs for quite some time (and some x86/amd64 ones when I encounter them), testing new kernel release candidates. This way you can ensure the linux kernel will continue to run on your goode olde ppc boxes. You don't need to code anything, you just need to know how to build a kernel and apply patches to the kernel. Having a 2nd machine with serial debugging or netconsole debugging via ethernet is also very helpful.

The PPC devs are very responsive in general if they get a bug report with a proper stacktrace (various debugging features turned on in the kernel) as are devs in general when you add the right subsystem maintainer to a bug report.

What you need is basically a quick read of the 1st part of https://wiki.gentoo.org/wiki/Kernel_git-bisect to get upstream kernel sources and a read of man patch. Getting the subsystem maintainer of a specific part of the kernel is also easy, e.g.

[GreenNeonWhale]

schwarzygesetzlos,

Thanks for your post, and in the info. I'm still hoping to get into some regular contributions soon. When I do, that info will be helpful. I have patched kernels before, but only in a basic way -- production ready patches.

As a PPC user, I appreciate your contributions to keeping everything going.

When I finally get some stuff ready, I'll make a point of posting some progress updates in this thread.