On Mon, 29 Oct 2018, Arnd Bergmann wrote:
[...] The real question that we tried to resolve is how we can more generally find out whether a driver is still being used or not when it gets in the way of some API conversion. [...]
I think you have to show that the driver or platform or arch has been broken for some mandated minimum length of time. More importantly, you also need to prevent developers from carelessly breaking legacy drivers. And there is a clear tendency among maintainers to abandon the usual standards of care and diligence when refactoring legacy code or reviewing other developers' patches to that code. (I've seen this happen again and again.) This leads to regressions that go undetected, or when detected, may go unreported by users*. Either way, the driver can get removed as being "unused". That result serves the interests of certain parties who happen to employ maintainers. You can avoid this moral hazard by use of automated refactoring and other tools (to prevent behavioural changes or prove equivalence) and by impartial review.
I brought up m68k in particular as it was used on the oldest machines I could find, sun3.
It's worth noting that the oldest drivers and ports are often the smallest. If your criterion for deleteion is age, you can expect rapidly diminishing returns. I think you need to quantify this problem. How much would your past API modernization effort have been reduced if there was no arch/m68k, or no CONFIG_SUN3? You can measure that in lines of code. You should also look at the portion of past modernization effort spent inside arch/m68k or #ifdef CONFIG_SUN3, and figure out how much of that effort could have been automated (given better tools). * Reporting regressions is not free. I suspect it is more efficient for a developer to avoid introducing the bug in the first place, than for a developer and a user to collaborate on fixing it. --
