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.

-- 

Reply via email to