From: josh@joshtriplett.org
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch <linux-arch@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
Date: Fri, 31 Jul 2020 14:27:21 -0700 [thread overview]
Message-ID: <20200731212721.GC32670@localhost> (raw)
In-Reply-To: <CAK8P3a2PK_bC5=3wcWm43=y5xk-Dq5-fGPExJMnOrNfGfB1m1A@mail.gmail.com>
On Fri, Jul 31, 2020 at 05:00:12PM +0200, Arnd Bergmann wrote:
> The majority of the code in the kernel deals with hardware that was made
> a long time ago, and we are regularly discussing which of those bits are
> still needed. In some cases (e.g. 20+ year old RISC workstation support),
> there are hobbyists that take care of maintainership despite there being
> no commercial interest. In other cases (e.g. x.25 networking) it turned
> out that there are very long-lived products that are actively supported
> on new kernels.
>
> When I removed support for eight instruction set architectures in 2018,
> those were the ones that no longer had any users of mainline kernels,
> and removing them allowed later cleanup of cross-architecture code that
> would have been much harder before.
>
> I propose adding a Documentation file that keeps track of any notable
> kernel feature that could be classified as "obsolete", and listing
> e.g. following properties:
>
> * Kconfig symbol controlling the feature
>
> * How long we expect to keep it as a minimum
>
> * Known use cases, or other reasons this needs to stay
>
> * Latest kernel in which it was known to have worked
>
> * Contact information for known users (mailing list, personal email)
>
> * Other features that may depend on this
>
> * Possible benefits of eventually removing it
We had this once, in the form of feature-removal-schedule.txt. It was,
itself, removed in commit 9c0ece069b32e8e122aea71aa47181c10eb85ba7.
I *do* think there'd be value in having policies and processes for "how
do we carefully remove a driver/architecture/etc we think nobody cares
about". That's separate from having an actual in-kernel list of "things
we think we can remove".
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
WARNING: multiple messages have this Message-ID (diff)
From: josh@joshtriplett.org
To: Arnd Bergmann <arnd@arndb.de>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>,
Mike Rapoport <rppt@linux.ibm.com>,
linux-arch <linux-arch@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
Date: Fri, 31 Jul 2020 14:27:21 -0700 [thread overview]
Message-ID: <20200731212721.GC32670@localhost> (raw)
In-Reply-To: <CAK8P3a2PK_bC5=3wcWm43=y5xk-Dq5-fGPExJMnOrNfGfB1m1A@mail.gmail.com>
On Fri, Jul 31, 2020 at 05:00:12PM +0200, Arnd Bergmann wrote:
> The majority of the code in the kernel deals with hardware that was made
> a long time ago, and we are regularly discussing which of those bits are
> still needed. In some cases (e.g. 20+ year old RISC workstation support),
> there are hobbyists that take care of maintainership despite there being
> no commercial interest. In other cases (e.g. x.25 networking) it turned
> out that there are very long-lived products that are actively supported
> on new kernels.
>
> When I removed support for eight instruction set architectures in 2018,
> those were the ones that no longer had any users of mainline kernels,
> and removing them allowed later cleanup of cross-architecture code that
> would have been much harder before.
>
> I propose adding a Documentation file that keeps track of any notable
> kernel feature that could be classified as "obsolete", and listing
> e.g. following properties:
>
> * Kconfig symbol controlling the feature
>
> * How long we expect to keep it as a minimum
>
> * Known use cases, or other reasons this needs to stay
>
> * Latest kernel in which it was known to have worked
>
> * Contact information for known users (mailing list, personal email)
>
> * Other features that may depend on this
>
> * Possible benefits of eventually removing it
We had this once, in the form of feature-removal-schedule.txt. It was,
itself, removed in commit 9c0ece069b32e8e122aea71aa47181c10eb85ba7.
I *do* think there'd be value in having policies and processes for "how
do we carefully remove a driver/architecture/etc we think nobody cares
about". That's separate from having an actual in-kernel list of "things
we think we can remove".
next prev parent reply other threads:[~2020-07-31 21:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-31 15:00 [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence Arnd Bergmann
2020-07-31 15:00 ` Arnd Bergmann
2020-07-31 21:27 ` josh [this message]
2020-07-31 21:27 ` [Ksummit-discuss] " josh
2020-07-31 21:57 ` Bird, Tim
2020-07-31 21:57 ` Bird, Tim
2020-07-31 22:47 ` josh
2020-07-31 22:47 ` josh
2020-08-05 17:26 ` Pavel Machek
2020-08-05 17:26 ` Pavel Machek
2020-08-05 18:50 ` [Ksummit-discuss] " Geert Uytterhoeven
2020-08-05 18:50 ` Geert Uytterhoeven
2020-08-05 19:30 ` Pavel Machek
2020-08-05 19:30 ` Pavel Machek
2020-08-10 19:39 ` Olof Johansson
2020-08-10 19:39 ` Olof Johansson
2020-08-16 12:53 ` Michael Ellerman
2020-08-16 12:53 ` Michael Ellerman
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=20200731212721.GC32670@localhost \
--to=josh@joshtriplett.org \
--cc=arnd@arndb.de \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.