On Tue, 16 Jun 2020, Bart Van Assche wrote: > > As far as I know the sbp driver only has had one user ever and that user > is no longer user the sbp driver. So, you estimate the userbase at zero. Can you give a confidence level? Actual measurement is hard because when end users encounter breakage, they look for quick workarounds before they undertake post mortem, log collection, bug reporting, mailing list discussions, analysis etc. > So why to keep it in the kernel tree? Answer: for the same reason it was added to the tree. Here's a different question: "Why remove it from the kernel tree?" If maintaining this code is a burden, is it not the kind of tax that all developers/users pay to all developers/users? Does this driver impose an unreasonably high burden for some reason? The growth of a maintenance burden in general has lead to the invention of design patterns and tooling to minize it. So a good argument for removal would describe the nature of the problem, because some driver deficiencies can be fixed automatically, and some tooling deficiencies can compound an otherwise insignificant or common driver deficiency. There are spin-off benefits from legacy code besides process improvements. Building and testing this sort of code has regularly revealed erroneous corner cases in commits elsewhere like API changes and refactoring. Also, legacy code is used by new developers get experience in code modernization. And it provides more training material for neural networks that need to be taught to recognize patches that raise quality. Ten or twenty years ago, I doubt that anyone predicted these (and other) spin-off benefits. If we can't predict the benefit, how will we project the cost, and use that to justify deletion? Please see also, http://www.mac.linux-m68k.org/docs/obsolete.php
