On Mon, Oct 29, 2018 at 2:58 AM Greg Ungerer <gregungerer@xxxxxxxxxxxxxx> wrote:
I have been working on and maintaining parts of m68k for a long time,
and I was not aware that there was a number of problem areas that are
causing real pain. Maybe a friendly email from subsystem maintainers that
see issues would go a long way. At least if the m68k (and other arch)
communities know they can work toward solutions sooner rather than later.
Talk of ultimatums seems a bit heavy handed when only one side seems
to be aware there is a problem.
Adding Ted to Cc, as he was the one that brought up the ultimatum, and
James who raised the broader question of the long-term prospects of
32-bit hardware.
I have to admit that I failed to direct the maintainer summit discussion
the way I had originally intended. I started off with the eight architectures
that got removed, as an example for stuff that was already known to
be basically completely unused (for mainline Linux), and how it took me
a long time to be really sure that we are not hurting any remaining users.
I did not think (and still don't) that we are going to be removing further
CPU architectures any time soon, with the possible exception of those
that no longer have any compiler that can build them (unicore32 only has
a gcc-4.5 binary that no longer works, hexagon has 4.6 sources and binary
that barely work).
The real question that we tried to resolve is how we can more generally
find out whether a driver is still being used or not when it gets in the
way of some API conversion. This most often involves drivers for PC
add-on cards (network, scsi, ide, isdn, ...) and old bus interconnects
(ISA, EISA, previously MCA), but can also affect architectures from those
days (alpha, parisc, m68k). The conflict here is that unmaintained and
unused drivers are a burden for any treewide API changes in
particular because there is nobody who can test or Ack the changes,
but removing those drivers too aggressively is certain to hit some
users that still require the drivers and simply update their kernels
too infrequently to test changes in time.
I brought up m68k in particular as it was used on the oldest machines
I could find, sun3: To my best knowledge, the last working version of
Linux on this hardware was 2.6.26 with the addition of a simple patch that
was (and presumably still is) needed to get access to the serial console.
My guess is that aside from the popular m68k platforms (amiga, atari,
coldfire and mac and a one or two I'm not familiar with), there is a lot of
code that has not been used on many years. The same thing is certainly
true of mips, ppc, sh, and arm, all of which could benefit from having
someone take a critical look at which platforms were actually ever
properly supported at any point. When we did that on ARM a few years
ago, we ended up removing several that seemed promising when they
initially got added but that were not completed before the people working
on them moved on, or that had worked at some point but stopped
compiling several years earlier without anyone noticing.
Arnd
