linux-kernel - RE: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 31 Jul 2020 21:57:41 +0000
From:   "Bird, Tim" <Tim.Bird@...y.com>
To:     "josh@...htriplett.org" <josh@...htriplett.org>,
        Arnd Bergmann <arnd@...db.de>
CC:     linux-arch <linux-arch@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ksummit <ksummit-discuss@...ts.linuxfoundation.org>
Subject: RE: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence

> -----Original Message-----
> From: josh@...htriplett.org
> 
> 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".

I'm not sure the documents are the same.  I think what Arnd is proposing
is more of a "why is this thing still here?" document.  When someone does
research into who's still using a feature and why, that can be valuable information
to share so that future maintenance or removal decisions can be better informed.

Maybe e-mails are sufficient for this, but they'd be harder to find than something in
the kernel source. But that supposes that people would look at the file, which 
appears didn't happen with feature-removal-schedule.txt.

 -- Tim