From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932619AbdEROyT (ORCPT ); Thu, 18 May 2017 10:54:19 -0400 Received: from helium.openadk.org ([89.238.66.15]:39200 "EHLO helium.openadk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932282AbdEROyS (ORCPT ); Thu, 18 May 2017 10:54:18 -0400 X-Greylist: delayed 495 seconds by postgrey-1.27 at vger.kernel.org; Thu, 18 May 2017 10:54:18 EDT Date: Thu, 18 May 2017 16:45:57 +0200 From: Waldemar Brodkorb To: Linus Torvalds Cc: Linux Kernel Mailing List , Hans-Christian Noren Egtvedt Subject: objective rules for architecture removal Message-ID: <20170518144557.GU11446@waldemar-brodkorb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Operating-System: Linux 3.16.0-4-amd64 x86_64 User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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