From: Arnd Bergmann <firstname.lastname@example.org> To: ksummit <email@example.com>, Mike Rapoport <firstname.lastname@example.org>, linux-arch <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org> Subject: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence Date: Fri, 31 Jul 2020 17:00:12 +0200 [thread overview] Message-ID: <CAK8P3a2PK_bC5=3wcWm43=y5xk-Dq5-fGPExJMnOrNfGfB1m1A@mail.gmail.com> (raw) I have submitted the below as a topic for the linux/arch/* MC that Mike and I run, but I suppose it also makes sense to discuss it on the ksummit-discuss mailing list (cross-posted to linux-arch and lkml) as well even if we don't discuss it at the main ksummit track. Arnd 8<--- 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 With that information, my hope is that it becomes easier to plan when some code can be removed after the last users have stopped upgrading their kernels, while also preventing code from being removed that is actually still in active use. In the discussion at the linux/arch/* MC, I would hope to answer these questions: * Do other developers find this useful to have? * Where should the information be kept (Documentation/*, Kconfig, MAINTAINERS, wiki.kernel.org, ...) * Which information should be part of an entry? * What granularity should this be applied to -- only high-level features like CPU architectures and subsystems, or individual drivers and machines? _______________________________________________ Ksummit-discuss mailing list Ksummitemail@example.com https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
next reply other threads:[~2020-07-31 15:00 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-31 15:00 Arnd Bergmann [this message] 2020-07-31 21:27 ` josh 2020-07-31 21:57 ` Bird, Tim 2020-07-31 22:47 ` josh 2020-08-05 17:26 ` Pavel Machek 2020-08-05 18:50 ` Geert Uytterhoeven 2020-08-05 19:30 ` Pavel Machek 2020-08-10 19:39 ` Olof Johansson 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='CAK8P3a2PK_bC5=3wcWm43=y5xk-Dq5-fGPExJMnOrNfGfB1m1A@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).