objective rules for architecture removal

objective rules for architecture removal

[Waldemar Brodkorb]

Hi Linus,

are there any objective rules for removal of architecture support from
the Linux kernel tree?

I recognized this week that avr32 support was removed recently.
https://lkml.org/lkml/2017/3/1/694

The major reasons are:
 - end-of-life for hardware
 - no upstream gcc (very old)
 - no users or distribution supporting it
 - shared driver code with ARM architecture

AVR32 has a working distribution (https://openadk.org) and some users.
A year ago Mario Haustein from Technical University Chemnitz submitted some
patches to OpenADK for better AVR32 support. They have approx. 100 devices in use. 
And I donated a NGW100 board to one of the u-boot maintainers to keep u-boot
support solid. 

It is possible to use gcc 4.4.7 with some patches, which was used a long time
in OpenWrt avr32 port:
https://cgit.openadk.org/cgi/cgit/openadk.git/tree/toolchain/gcc/patches/4.4.7

I always loved that Linux kernel does support many architectures and keep supporting
all of them. Any chance to rethink about the removal?

Couldn't be the shared drivers be separated, so that the ARM drivers get there 
new improvements? It is a naive assumption from an embedded Linux hacker
trying to keep uClibc and all it's architecture support alive. 
(https://uclibc-ng.org)

best regards
 Waldemar

Re: objective rules for architecture removal

[Linus Torvalds]

On Thu, May 18, 2017 at 7:45 AM, Waldemar Brodkorb <wbx@openadk.org> wrote:
>
> are there any objective rules for removal of architecture support from
> the Linux kernel tree?

Objective rules for that in particular? No.

We do have the whole "no regressions" rule, which covers pretty much
anything except for bad security issues that can't be fixed any other
way (and then we really do try to find alternatives that fix the
problem without breaking whatever application depends on bad
interfaces).

But even with regressions, it's also an issue of "if there's only one
or two technically savvy users" and they can fix the regression
outside of kernel work. That comes up if we have some odd kernel
command line thing that some kernel developer used - we just tell him
to use a new command line instead.

So even that "no regressions" rule isn't _entirely_ black-and-white,
although it's about as close to a hard objective rule we have in
kernel development.

> I always loved that Linux kernel does support many architectures and keep supporting
> all of them. Any chance to rethink about the removal?

So what I think would need to happen is:

 - somebody who maintains it and is motivated

 - minimizing the cost of maintenance to everybody else

 - re-introduce the architecture not as a revert, but as a
re-instatement of the minimal possible support that is actually used
by people.

There is an existing example of this: the H8/300 architecture
(arch/h8300) was removed in Nov 2013, and then re-introduced in June
2015 in a cleaned-up form:

 - removal commit: 55a7d4b85ca1

    195 files changed, 9 insertions(+), 11743 deletions(-)

 - added back in: 4b4d2b463461

    123 files changed, 7597 insertions(+), 28 deletions(-)

And you can see how the re-introduction was noticeably smaller than
the original removal.

And in fact, that "re-introduced in a cleaned-up form" as opposed to
just reverting the removal is fairly critical for me for a
meta-reason: it shows that whoever wants to resurrect the architecture
is serious about it and willing to put in some effort into it.

So there is absolutely no reason it can't be resurrected, but it does
require some work on the part of whoever wants to do so.

                  Linus