On Fri, Jul 31, 2020 at 09:57:41PM +0000, Bird, Tim wrote: > > -----Original Message----- > > From: josh@xxxxxxxxxxxxxxxx > > > > 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. Ah, I see. So this *isn't* about "features we want to remove", this is "features people might think we should remove, but here's the documentation for why we aren't"? More of an obscure-but-still-wanted-features.txt?
